Brevet FR2983991A1 — publié le 20130614

I procédé de gestion d'alertes hétérogènes d'un système d'information Résumé: Ce document a pour objectif de regrouper toutes les règles et définitions du code de normalisation employé dans l'objectif d'unifier les informations de sécuritéHistorique des Versions SOMMAIRE 1 INTRODUCTION 11 PARTIE I - DESCRIPTION SCIENTIFIQUE DE L'ONTOLOGIE EXAPROTECT. 12 1.1 1 INTRODUCTION 12 1.2 2 ÉTAT DE L'ART 14 2.4 Dieramiee U 1.3 3 THEORIE DE L'ACTION EN PHILOSOPHIE 17 81 L'ùrdentierk18 82 Le 010k4Venent ,,18 83 Lu o'biete 18 1.4 4 ONTOLOGIE DES ALERTES 19 4,1 Oêmeee (t'un attaquant,. , /9 4,2 Les tale siens dam le Si 20 4.. Les preuvements dein le Si . 2/ 4,4 Les Qbjets du St . 2/ 4'e; Gais 22 4,6 6 PARTIE I - SPECIFICATION GENERALE DE LA NORMALISATION EXAPROTECT 29 . 1 PROCESSUS DE MODELISATION 29 1.1 ONTOLOGIE 29 1.2 PROCESSUS DE MODELISATION EXAPROTECT 30 /2./ Cteseesatien des actietts 30 t 2.2 1.3 LES MODELES EXA 31 1.4 MODELES D'ACTION 31 m., t4'2 tep.,4 Activite . ' 34 1,45 1.5 MODELE D'INFORMATION EXA : ETAT DU SYSTEME 36 2 LANGAGE EXAPROTECT 37 2.1 ROLE DE L'ANALYSTE DE SECURITE 37 2.2 DESCRIPTION SYNTAXIQUE D'UN MODELE EXA 37 2.3 DESCRIPTION LEXICALE DES 5 CONCEPTS DE L'ONTOLOGIE 38 2.31 2,32 Activie (ACTIVSTY) et MOUVEMENT 38 Taie (0219,Y 38 234 Resultat (RESULT) 38 2.4 VALEURS LEXICALES POUR LES 5 CONCEPTS 38 2.5 LEXIQUE POUR INTENTION (OBJECTIVE) - 39 2.6 LEXIQUE POUR ACTIviTY ET MOUVEMENT - 39 2.e2 at,3 Tatget Type, Tweet deta, e.4 3 OUTIL DE NORMALISATION 42 3.1 PRINCIPE DE LA MODELISATION D'ALERTE 42 3.2 MODELISATION DE LA CONNAISSANCE EXPERTE 42 a2.1 a2,2 Appeche pregreetique de le madesatien de ta cemajzsatzce elle@ 3.3 PROCESSUS DE NORMALISATION 44 Appiddie pragmatique du pomma de 3a2 Pieekeette de demelisatien expie et iule-cite de ta coendieedence','''''', 45 Fele e 46 333 Exemple de tapplieatien de pi eu de delmaUsatiwi 3a4 Exemple cfappllcatien 48 3.4 INTERPRETATION DE L'ALERTE NORMALISEE 48 PARTIE II - SPECIFICATIONS DETAILLEES DE LA NORMALISATION EXAPROTECT. 48 3.5 LE COEUR DU PRESENT DOCUMENT : L'OUTIL DE NORMALISATION 48 FIGURE 20 49 1 DE:FINITION DES INTENTIONS (OBJECTIFS) 49 AtiTHENTICAT4C1L .50 R4GHTS 52 SYSTEM 54 2 DE:FINITION DES ACTIVITES (ACTIVITY) - 56 ACT/V/7Y Men INFORMAT4ON 56 ATTACK 56 AMLWARE 56 SUSP'C4OUS 56 3 DE:FINITION DES ACTIVITES (MOUVEMENTS) 57 3.1 AUTHENTICATION_ACTIVITY 61 Categotte.: Cat(egetie: Ca te/xi& Ceidegiez 3.2 AUTHENTICATION_CONFIG 68 CatEigee Caegoiie Catfegeiez Catfeggsier CatÉigoitez UNLOCK, T AUTHENTICATION_INFORMATION 78 Catêgwie.:. CONTROL, , 78 Ca ego( THRESHOLD 80 AUTHENTICATION_ATTACK 82 Catêgoeie.:- Catdgegier o3 vacatee inintakiekt HTT427.- FHFB8 Admire ewthentication Bypaes 0x40220209Catêgefie.:- DOS Cakigwie Catêgtuie.: Catêgefiez INFORAeATIONG.ATHERING '','',',','','',',88 Catdwie INFORUATIONGATHERING Catdgefie INFOF?MATIONLEAK &fi Catdgeiie INJECTION 89 Catdpitier OVERFLOW. '90 Catêpete VIOLAT/ON, Cattegwie OTHER . Ca Lège& VIRUS, '93 Catêefie.: 3.3 AUTHENTICATION_SUSPICIOUS 95 Cake/rie Catdswite. CatijgEgie Catdsofiez INFOR/VATIONGATHERING'',''',','',''','''',,,'''','',''-','''''',',,,',98 Catagoile INFORIVAT IONLEA . . . . . ' ,' ' . . ' ' . .98 Cabegefe INFORIVATIONLEM ' , 99 Catêgorie INJECTION. . Catêgwie Catêgarie Caegwie Catêgwie Catégwie Catêgwie Catêgwie CattegeÉge- DOS Catiegwie GAIN . . /09 Catêgwie HUACK1NG . 110 Catêgwiez INFORtterATIONGATHERING ','',','''''-------','''''''''''''' , 111 Catêgwice Catfigwie CaWgwie Catêgwie.:- Catégeie Catêgwie Catêgwie Catêgwie.:. VICLATION''..',''''''''..'....''--','''',..,', 118 Ck, tdgetie VIOLATION 119 Ca begeite.: VIRUS. 120 3.4 RIGHTS_ACTIVITY 121 Catêgwie GAIN 121 Ca têgwie Catêgwie- tNR/TE, 125 Catêgwie DELETE Catégwie Ca têgwie RIGHTS_CONFIG 132 Catêgwiez Catêgwie Catêgwiez .15 RIGHTS INFORMATION 137 CWêgwie.:- CONTROL, 137' Calêswte.:- THRESHOLD /39 Cattegefie Catêgoiie. DIRECTORYTRAVERSAL'_,'''--',',','',''..',..'''-'',..,,,,,'''',''''''' 141 Catêgorie Cateepiie. INFORUATKINGATHERING -','',','','..'..'.----___'...''''',','''''' 143 Categuie INJECVON. /44 Ca/40,6w OVERFLOW /45 Catdgerie V/CLATION 146 Catégee.:- OTHER . 147' 36 RIGHTS_SUSPICIOUS 148 Catégorie Cabjegie RIGHTS_VULNERABILITY 151 Catégorie- Caidgefite SYPASS. . 152 CaIdeuriez DIRECTORYTRAVERSAL__''''''''''''''''''-------_''','-- /53 Catdeuie: Ca tee:Ife EVASJOU /55 Catdgeite GAIN, , , ' ' 156 Catdgefie INFORUAVONGATHERING 15T Catdgefie INJECVM tee Cabegeie OVERFLOW 159 Catêgete Catiegetie CaIdgefiee Catêgolliez 3.8 SYSTEM_ACTIVITY 163 Cattegutie.:. CONNECT4ON-___','''' ,,,,,,,'''.....,.,....'--','',',''',..'''''''''',..',, /63 Catagexie. Catf3seuie.:- Ca têggrie.:- Ca[êsew RECE/VE ....... . . 167 Ca têgoite.:. SENO. tee Cattegwie.:- STARTED, 171 CaZdgenez Calêswie: Cabegefie: UP 114 Caegwiez CatêgQiie CabegueeCetdeedie:- Catdgetio.:' RESTORE 180 Catêgarie- CONTROL. , 131 3.9 SYSTEM_CONFIG 183 Cattiewie Catêgailify- Catêsexie: 186 3,/0 SYSTEM_INFORMATION 186 Catégorie.: Catêgwiez 314/ CISCO-SWITCH.RULES 185 INSUFISANT mEmoRySYSTEM_ATTACK 190 ait SYSTEM_ATTACK 191 Caegfeie.:. eACKDOOR. 191 Catêgoeie aouNcE 192 Cat(egaifie- CONCEALMENT, 193 Cattïgaiie:- Dos. 194 Catêsee Catageez D1RECTORYTRAVERSAL ,,, '''''''''''' 195 Cake/rie Catêswite Cake" CaPegalie Cabjwie INFORWAT4ONGATHERING ,''''',,''''''---',''''''''--,,,,,,,,,,,- 200 Catejscuie Catêgoifiez 203 Cakeee PHiSHING Catégee204 Catêgaiie' Catêgwie Catêgarie- CatagoÉe SPOOFING' 2a8 Catêgee STEN. . 209 Catêgafie: /12 SYSTEM_MALWARE 211 Catêselie P2P 211 Cat4wie Caegoitie Catêgwie CaidgeeiteCatêgotite 3./3 SYSTEM_SUSPICIOUS 217 Catiesolie 80UNCE 2/T Catêgielie. CONCEALMENT 217 Catageuie CONCEALMENT, 218 Catagerie DOS .2/9 Gable/ie. Catasofie- Catégefie Catijgefle INFORVAPONGATHERING ',''''''''''''-''''',',''''''''''','',',' 223 Cabegetie Catagew Catêgolie. CaidgefiEe SPOOFING'''-'',',-,,''''''','','''',- 225 Cateeide CatêgwieCaegee Caegorie OTHER , - 229 314 SYSTEM VULNERABILITY 229 a14 SYSTEM_VULNERABILITY 230 Catêgwie Catdegie Catêgeae: Catagwie 4 Cattegerie Catégorie Catégorie- Catégorie INFORIVATIONGATHERING '' ,,, ,, ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 238 Categotie' INFORMATIONLEAK ,..',','',','''',''''''''',''''',,,''..''''__',''','' 239 CaIsegosiez IMJECTION' 240 Catégorie OVERFLOW 24/ Catégorie P2P 242 Categotie PHYSiCAL 243 Ca tégatie- Ca tegetie Catégorie Catégorie Catégorie Catégorie. TROJANObjectit SYSTEM VULAIERAEILITY __'''' Catégetie: Categetie. V4OLATION 25/ Catégerie- VIRUS. 252 Catégetie. WoRm ' . 2-5,3 Catdgesie- OTHER 254 4 MODELISATION DES CIBLES 255 4.1 CIBLES POUR « AUTHENTICATION » 258 41./ eavelieatiork de relthentificiation''''''''''''',,'',','''',..',.._''..','' Comptes «tiksatews pelf t'authentification 250 Attitede et dermdes de% co,tripte% taisateros 260 Lie» Eleepeeziblee peur tee meuveiereents crauthentilicatioe 260 4.2 CIBLES POUR « RIGHTS » 268 Gletip/a4 -Peattatue pewrratitheretillcatiore 268 pmpiete paitieJefue4 - - , 268 4.3 CIBLES POUR SYSTEM 279 Equi peinante 27 Ob.èste «haat. 2 c. 9 Rotocoles 281 Services 282 Servieue eauspaeidques-A,pplioations ..............:,..,..,..:,:.,.,..,....,..........:....,....:,.... Applications ee Attaittne et amen système 28 Exectgables 287 ExectiteMes 287 1 Introduction Ce document propose de décrire la normalisation créée par Exaprotect. Le principe des sources de surveillance est d'émettre une alarme destinée à l'analyste de sécurité chargé de surveiller les différents assets du système d'information. Une alarme n'est autre qu'une phrase en langage naturel qui décrit ou dénonce une action observée. Le but de cette alarme est que l'analyste puisse ensuite appliquer une contre mesure. Il en découle que de la précision et de la pertinence de l'alarme déclenchée découle la pertinence de la contre mesure. Les sources de surveillances sont nombreuses et variées, elles peuvent aussi bien être des sondes de détection Comme nous venons de le préciser les évènements qui parviennent à l'analyste ne sont pas structurés et peuvent exprimer une seule et même action à l'aide de toute une variété de termes. Le volume d'alarmes que doit analyser l'analyste est énorme, il représente plus de 30 000 types d'alarmes différents issues de plus d'une centaine de sondes différentes. Toutes ces alarmes quel qu'elles soient sont collectées sur une base d'information centralisée et la quantité moyenne journalière à traiter varie de 1 go à 100 go par jour. Le rythme d'entrée des alertes dans la base peut atteindre 1 000 alarmes par seconde. Face à de tels volumes, l'analyste de sécurité est impuissant et doit faire appel à des outils, appelés mécanismes de corrélation et d'agrégation capables de réduire ce volume en associant : les alarmes qui signifient la même chose les alarmes qui appartiennent au même défaut : attaque ou faute système les alarmes qui décrivent des attaques de celles qui décrivent des pannes les alarmes qui sont en réalité des faux-positifs et celles qui appartiennent à des faux-négatifs supposés. Les alarmes qui sont émises par les sondes de surveillance sont appelées des évènements ou log bruts, les alarmes qui sont transformées par le processus de normalisation ExaProtect sont appelées des alertes. Les modèles de références décrivant les catégories et définis grâce au processus de modélisation sont appelés des modèles Exa (parfois des catégories ou alertes de référence). L'humain qui crée les modèles Exa et définit les règles associées est un expert de sécurité, il définit aussi les règles de transformation d'un log brut en alerte. L'humain qui analyse l'alerte émise afin de définir des contre mesures adaptées est l'analyste de sécurité. L'analyste ne peut connaître la totalité de ces évènements. De même, les mécanismes de corrélation ne seront opérationnels que sur des données structurées La première étape à réaliser avant d'assister l'analyste dans sa tâche de détection, de corrélation ou encore de réaction est de fournir à l'analyste un outil pour classifier cette masse énorme d'alarmes. ExaProtect a conçu sa propre normalisation en s'appuyant à la fois sur la connaissance de ses experts en sécurité et sur ses propres travaux de recherche. La normalisation ExaProtect se présente sous deux volets distincts : a modélisation qui représente un processus de définition des alertes ; le processus de modélisation permet de définir la connaissance experte indispensable à un système de surveillance. Notamment il va définir les modèles de donnée en entrée et trouver les concepts pour présenter les données pertinentes du système de surveillance. Le résultat de cet étape est l'obtention de modèle Exa. la transformation (appelé normalisation) des logs bruts en alertes ; le processus de transformation est un outil basé sur les outils linguistiques en intelligence artificielle pour assister pleinement le travail d'expertise. La connaissance experte est à ce stade Indispensable pour apporter les règles de normalisation. La modélisation ExaProtect est un outil qui a permis de définir une classification reflétant toutes les activités qui ont lieu au sein du système d'information (SI). Chaque évènement représente une activité et chaque activité est une catégorie de la classification. La normalisation a pour objectif de fournir une donnée structurée compréhensible par un analyste de sécurité ou un mécanisme automatisé pour optimiser les traitements d'un tel volume de logs brut. Grâce à la normalisation un analyste de sécurité recevra une alerte candidate représentative de toutes les autres alertes de même nature. Le document s'articule en 4 parties : o la description de la méthode de modélisation, o la présentation du langage ExaProtect qui permet de décrire en expression logique les modèles Exa, o la présentation de la méthode de normalisation (transformation), o la définition de l'ensemble des modèles Exa. L'ensemble des alertes utilisées pour la classification des informations de sécurité ont été recueillies par le logiciel ESMS de ExaProtect, déjà implanté. Partie I Description scientifique de l'ontologie ExaProtect. 1.1 1 Introduction Ces dernières années, la recherche dans le domaine de la détection d'intrusions s'est dirigée vers un déploiement distribués d'équipements de sécurité ; ces équipements réalisent une détection locale et fournissent ainsi des informations permettant d'effectuer la détection globale des intrusions. Parmi ces travaux nous pouvons citer les systèmes DIDS [30], GrIDS [28], EMERALD [25] et AAFID [34] appelés système de détection d'intrusions coopératif. La détection globale est effectuée par un automate de corrélation qui traite les alertes remontées de différentes sources de surveillance. La corrélation [8, 22] part du principe que les intrusions contre les systèmes d'informations sont guidées par un but et constituées de plusieurs étapes permettant d'atteindre ce but. La corrélation consiste alors à associer les étapes franchies en un scénario d'intrusions, ce qui permet ainsi de fournir une vision globale à l'analyste en lui présentant les stratégies d'attaques. La faiblesse des systèmes actuels provient du fait que seuls les évènements de sécurité sont pris en compte pour réaliser la corrélation. Or, de nombreux évènements issus d'équipements de supervision ou issus d'applications apportent des informations fondamentaux pour la détection d'une intrusion. Dans notre démarche, nous proposons une architecture illustrée sur la figure 1 qui consiste à faire coopérer non seulement les sondes des équipements de sécurité (IDS, Firewall, Antivirus..) mais aussi les superviseurs du réseau, des systèmes ou des applicatifs. Une telle architecture nous permet d'avoir une vision globale du Système d'Information (SI), un enrichissement des alertes de sécurité et une vue synthétique. Elle permettrait aussi à l'analyste de réagir et d'arrêter une attaque en cours en corrélant des alertes remontées par un audit système ou applicatif avec des alertes émises par des équipements de sécurité. Par exemple, nous pouvons anticiper la détection d'une attaque de type déni de service en surveillant la brusque augmentation de l'usage d'un espace disque. Les systèmes de surveillance actuels analysent les évènements et remontent des alertes au système central de corrélation. Généralement, les travaux de recherches partent de l'hypothèse que les sondes émettent des alertes homogènes. Le monde industriel quand à lui, propose pour chaque produit une normalisation ad hoc sur un sous ensemble de sondes. Nous résumerons la notion d'équipements de surveillances à celle de sonde pour le besoin de notre discours. L'intéropérabilité de ces différents modèles de normalisation n'est jamais réellement abordée. De plus, le traitement combiné d'évènements d'origine réseau ou applicatif est encore plus difficile dans un tel contexte. Chaque acteur possède sa propre interprétation pour modéliser les évènements au travers sa propre syntaxe et son propre lexique. En résulte que chaque analyste de sécurité se fonde sur sa propre expérience pour leur interprétation. De même, chaque organisme et chaque constructeur de sonde possède leur culture interne menant des définitions hétérogènes. Figure 1: Vision globale Une traduction de ces alertes via une syntaxe et une sémantique commune, compréhensible et traitable par les mécanismes de corrélation, est nécessaire. La sémantique ne permet pas seulement la structuration de l'information mais aussi le raisonnement sur le sens de l'information. Sans cette connaissance, l'administrateur de sécurité ou l'automate de corrélation ne pourra pas corréler ces informations. Un modèle de données a déjà été proposé au travers de l'IDMEF (Intrusion Detection Message Exchange Format)[9] par le groupe de travail IDWG (Intrusion Detection Working Group) à l'IETF (Internet Engineering Task Force). Il permet notamment la coopération des sondes en proposant une structure commune aux alertes. Un message IDMEF contient le nom d'un événement via le champ classification text ; le nom de l'événement exprime la sémantique du message. Cependant, ce champ n'est pas structuré, IDMEF se préoccupant uniquement de définir un modèle de données pour l'alerte mais pas sa sémantique. Nous adoptons dans notre travail ce format de donnée pour structurer les alertes et nous nous focalisons sur le champ classification text en proposant une modélisation de la sémantique de l'alerte commune aux différentes sondes. Du point de vue de la corrélation, ce modèle de données est efficace si le message porté par l'événement et qui en définit la sémantique, est codifié de façon homogène au niveau de chaque sonde. Or, la plupart des équipements dispose de leur propre schéma de classification , d'autres ne disposent d'aucun schéma, ne définissant que de simples catégories. Avoir un format commun pour les alertes n'est 'La classification est le processus qui permet de séparer les objets en classes ayant des caractères communs pas suffisant, si la description du message n'est pas décrite explicitement dans chaque sonde. En plus du format de l'alerte, nous avons donc besoin d'une classification commune ou plus précisément d'une manière de définir la connaissance du domaine par un haut niveau d'abstraction. Il existe deux approches de classification qui sont la taxonomie et l'ontologie. Une taxonomie est un schéma de classification simple à utiliser par l'être humain alors qu'une ontologie est un schéma plus élaboré destiné à décrire les connaissances à un niveau plus opérationnel exploitable par des logiciels. Les algorithmes de corrélation, quels qu'ils soient, relient des alertes pour former puis détecter des plans d'intrusions. Pour cela, ils reposent sur la description ou plus précisément sur la sémantique de l'alerte pour décider de créer un lien entre elles. Cette sémantique ne doit pas être exprimée comme elle l'est actuellement sous forme de messages textuels, car les automates de corrélation ne peuvent pas raisonner sur une description non structurée. De nombreux travaux de recherche ont tenté de classifier des alertes[23, 24 , 7, 17, 19, 15, 31, 27, 5, 6], mais la majorité ne propose que des classifications sans s'attacher à la sémantique. Certains travaux, en revanche, ont proposé une ontologie [33], mais la sémantique retenue était exclusivement liées aux attaques. Nous proposons dans cet article une modélisation des alertes sous forme d'ontologie, notre modélisation offrant une abstraction des sondes. Cette modélisation se fonde sur les travaux issus de la philosophie. Ces travaux ont permis d'une part de trouver les concepts nécessaires à notre modélisation et d'autre part, sur l'étude du comportement de l'attaquant pour définir toutes les activités à surveiller dans un SI. Nous avons spécifié notre ontologie en utilisant le langage OWL(Web Ontology Language) [21] et cette ontologie a été appliqué à 20182 alertes hétérogènes issues de 123 sondes différentes. La section 2 décrit les travaux de recherche effectués dans le domaine de la modélisation des alertes. Les aspects de la théorie de l'action sont décrits dans la section 3. Notre ontologie est décrite dans la section 4. La section 5 décrit les résultats de l'application de notre ontologie à large exemple et la section 6 apporte une conclusion à notre approche et propose des perspectives de développement à nos travaux. 1.2 2 État de l'art La littérature scientifique propose de nombreuses classifications. Nous avons trouvé trois approches pour la description des attaques : les taxonomies, les ontologies et les langages de description d'attaques. 2.1 Les taxonomies d'attaque De nombreux auteurs [1, 19, 15, 18, 2] ont identifié que certaines caractéristiques sont nécessaires pour que la taxonomie soit suffisante et acceptable. En combinant leurs travaux, une taxonomie doit être : Concensuelles logique et intuitive de sorte que les catégories sont acceptées par une majorité des membres de la communauté, Convenable : répond au besoin pour lequel elle a été développée ; par exemple est ce qu'un comportement intrusif est présent ou pas? Compréhensible : pour les experts de sécurité et pour ceux qui ont un intérêt à l'utiliser, Exhaustive : toutes les attaques peuvent être décrites et chaque taxonomie incluant la catégorie "other" pour la rendre exhaustive, Déterministe : les actions décrivant le même phénomène sont toujours couvertes par la même catégorie, Mutuellement exclusive : chaque catégorie est complètement différente des autres et ne peut pas contenir d'autres catégories, Spécifique : conforme à la terminologie de la sécurité, Non .ambiguë : la classification d'une attaque est toujours la même, indépendemment de la personne qui la classifie, Applicable : utile pour rapporter les incidents ou pour effectuer des requêtes. Les taxonomies les plus simples proposent un ensemble de termes qui regroupent des aspects variés d'attaques [7,17], sans utiliser de critères pour la classification. Le nombre de termes diffère d'un auteur à un autre. Certaines alertes ne pouvant être représentées par aucun terme proposé. Les propriétés des attaques ne sont pas séparées et par la suite les termes ne peuvent pas être mutuellement exclusifs. La liste doit être suffisamment exhaustive pour couvrir tous les types d'attaques. Même si nous supposons que la liste est exhaustive, la taxonomie devient difficile à appliquer et à faire vivre. Un autre type de classification consiste à regrouper les alertes dans des listes de catégories suivant des critères spécifiques. Le nombre de catégorie change d'un auteur à un autre. Ce schéma de classification apporte une amélioration par rapport au précédent : les attaques individuelles ne sont plus décrites par un simple terme pris dans une liste, mais par une catégorie prise dans un ensemble plus restreint mais avec une sémantique plus riche. Cheswick et Bellovin dans [5] ont développé une liste de sept catégories ; chaque catégorie est définie par une description et c'est la description de la catégorie qui guide le processus de classification. Stallings [31] se base sur l'action. Le modèle se focalise sur les données en transit, il définit quatre catégories d'attaques : interruption, interception, modification et fabrication. Dans [6,27] les auteurs se sont intéressés à regrouper les alertes selon les effets ou les conséquences des attaques. En utilisant les "résultats" comme seul critère de classification, certaines alertes pourraient ne pas être modélisées, notament celles qui n'ont pas d'effets: cas d'une alerte qui informe que l'authentification est nécessaire sur un service. D'autres auteurs ont pu construire leurs taxonomies sur des données empiriques. Chacun d'eux s'appuye sur un corpus d'alertes généré dans un environnement spécifique pour développer une liste de catégories. Neumann et Parker se sont basés sur un corpus de 3000 incidents collectés pendant 20 ans [24], et ont créé neuf classes en fonction des techniques d'attaques utilisées. Neumann [23] a étendu la classification de [24] en ajoutant les vulnérabilités exploitées et l'impact de l'attaque [23]. Bien que ce soit une amélioration par rapport au premier schéma, ces taxonomies qui développent une liste de catégories souffrent des mêmes problèmes que liste de termes.. En outre, en utilisant un seul critère, le nombre de catégories devient très grand, la taxonomie devient difficile à gérer par l'analyste et l'information présentée à l'analyste est pauvre. Linclqvist et Jonson [19] présentent une classification qui s'appuye sur le schéma de classification proposé par Neumann et Parker en 1989 [24]. Ils ont étudié un corpus d'alerte généré par une expérience d'intrusions. Ils ont introduit un nouveau concept : chaque attribut dans la description de l'alerte (source, cible, moyen ...) est traité comme une dimension. Leur classification est élaborée du point de vu du propriétaire du système : ils ont retenu les techniques d'attaque et l'effet d'intrusion comme dimension pour décrire les alertes. Seule trois classes sur les 9 du schéma de classification de Neumann et Parker [24] ont été réutilisées et raffinées. D'autres approches comme celles proposées par Howard [15] et le laboratoire SANDIA [14] sont complètement différentes des premières : elles orientent la taxonomie avec un processus de classification qui reflète le mode opératoire de l'attaque, de la source vers l'objectif. La taxonomie proposée par Howard [15] définit l'attaque par les types d'attaquants, les outils, les accès, les résultats et les objectifs. L'auteur a travaillé sur les incidents du CERT (Computer Emergency Response Team) sur Internet de 1989-1995. L'ambiguïté pour classifier une information d'attaque n'est pas soulevée. Il est difficile de faire la différence entre "Script or Program" et "Toolkit" dans la catégorie "Tools", autant que de faire la différence entre les actions de Professional Criminels et de Terroristes dans la catégorie Attackers. La taxonomie d'Howard représente la base de la taxonomie proposée par le laboratoire SANDIA en lui ajoutant quelques catégories et en étendant d'autres [14]. Les catégories de la classification reposent sur les attaquants, les outils, les vulnérabilités, les actions, les cibles, les résultats non autorisés et les objectifs. 2.2 Les ontologies sur les attaques Les limites des taxonomies ont poussé d'autres auteurs à fournir des efforts dans le domaine de la classification des attaques et a conduit à définir une ontologie pour les événements d'intrusion. Undercoffer et al [33] furent les premiers à proposer cette approche. Une ontologie est un système structuré de concepts qui couvre un domaine spécifique et qui permet de construire un modèle représentatif de la réalité. Dans le but de construire une ontologie, les auteurs ont commencé par le développement d'une taxonomie dont l'objectif est d'offrir une vue générale du système. Leur taxonomie est constituée par la cible, les moyens, les conséquences d'une attaque et l'attaquant. La taxonomie a été étendue à une ontologie, en définissant les différentes classes, leurs attributs et leurs relations. Les auteurs se sont basés sur un corpus de 4000 alertes pour décrire leur domaine. Ils ont employé leur ontologie pour détecter une attaque distribuée. 2.3 Les langages d'attaques Plusieurs auteurs proposent la détection d'intrusion à travers des langages d'attaques. Ces langages sont conçus pour décrire les manifestations d'attaques dans un format approprié. Ils sont utiles pour analyser les relations entre différentes attaques. Leur but est d'identifier les attaques coordonnées contre le système. Ces langages sont classifiés en six classes distinctes selon [13]. Les langages de description d'exploit sont utilisés pour décrire les étapes suivies pour exploiter les failles et les vulnérabilités dans le système. Les langages d'événements sont utilisés pour décrire les événements. Ces événements sont les données de base d'un processus d'analyse. Cette classe de langage se focalise sur la spécification du format de donnée. Les langages de détection sont utilisés pour fournir les mécanismes identifiant la manifestation d'une attaque. Les langages de corrélation attirent actuellement l'intérêt de plusieurs chercheurs. Ces langages se basent sur la sémantique des alertes provenant des différents systèmes de détection d'intrusions. Ils spécifient les relations entre les attaques pour identifier les attaques coordonnées contre le système. Les langages de description d'alertes sont utilisés pour décrire les informations sur les attaques détectées. Les langages de réaction sont utilisés pour exprimer les actions à prendre pour réagir devant la détection des manifestations d'attaques. Ces langages ont des caractéristiques différentes mais sont utiles dans le contexte de détection d'intrusion suivant des environnements particuliers. Ils s'appuyent sur des modèles d'alertes ou d'événements pour effectuer leur modélisation. Ils ne modélisent pas la sémantique de l'alerte mais ils utilisent implicitement des taxonomies d'attaques dans leur modélisation. 2.4 Discussion Tous les travaux de recherche cités ci-dessus ne donnent qu'une vision partielle du système surveillé, ils se sont focalisés sur la conceptualisation des attaques ou des incidents (ce qui est dû à la prise en compte d'un type unique d'équipement : l'IDS). En réallisant un audit des différents composants du SI, nous pouvons avoir une vision globale grâce à la corrélation des traces d'audit avec les attaques remontées par les sondes de détection, permettant de reconstituer la démarche de l'attaquant. Le champ d'application des alertes à classifier est vaste, elles peuvent être des données d'entrée pour un moteur de corrélation, utiles pour faire le reporting ou exécuter des requêtes ou encore pour faire des statistiques. Toutes ces applications, exigent un traitment automatique de l'information vu le nombre d'alertes générées dans un système surveillé. Le processus, qui doit gérer ce traitement, doit pouvoir raisonner sur ces données. Undercoffer et al [33] proposent une ontologie pour décrire les attaques c'est à notre connaissance une première solution au problème de classification des attaques qui utilise une ontologie. Les auteurs ont montré leur efficacité pour faire coopérer des IDS afin de détecter les intrusions. Nous avons besoin d'une modélisation des informations de sécurité en faisant abstraction des sondes. Une modélisation qui n'impose pas à l'analyste de connaître le langage de chaque sonde. Une modélisation qui guide le processus de classification et qui lève l'ambiguïté pour classer une alerte : ce qui peut être utile pour la corrélation. Une modélisation avec une sémantique qui peut être implantée dans une application afin que l'application puisse mener un raisonnement. Nous avons besoin d'un modèle qui reflète la réalité. Nous allons proposer dans ce qui suit une ontologie beaucoup plus complète, elle ne s'appuye pas seulement sur les attaques mais elle prendra l'ensemble des activités surveillées du SI. 1.3 3 Théorie de l'action en philosophie Nous avons conclu que nous avons besoin de faire une abstraction des sondes pour ne pas se focaliser sur le langage de chaque sonde. L'abstraction des sondes nécessite la représentation des alertes sur les concepts manipulés par les sondes mais avec un langage partagé. La description de l'alerte est fortement liée à l'action perçue par le système, cette action pouvant être observée à n'importe quel moment de son cycle de vie : son déclenchement,sa fin ou son interruption. Un message d'alerte peut donc informer qu'une action vient de démarrer, qu'elle est en cours, qu'elle a échoué ou qu'elle est finie. Le message d'alerte dépend du niveau d'avancement de l'exécution de l'action ; il peut décrire une action ou un état d'un composant du système vers lequel l'action était dirigée. Il n'est pas trivial de trouver une modélisation commune pour ces différentes informations. Pour simplifier, nous avons retenu la modélisation des alertes via le concept d'action observée. Nous obtenons ainsi une modélisation qui s'adapte à tout type d'observation. L'analyse conceptuelle est un champ de la philosophie, tout autant un outil, nous travaillerons à l'aide de la théorie de l'action pour aborder ce problème. Dans les paragraphes suivants nous aborderons les travaux qui ont été faits dans le domaine de la théorie de l'action, et nous esquissons une adaptation de ces travaux à notre contexte. 3.1 L'intention Selon le modèle classique de l'action expliqué par Davidson [11, 12,26], les actions (humaines) sont susceptibles d'être décrites par une explication rationnelle. Une telle explication a pour but de rendre intelligible une action en indiquant les raisons qu'a eues l'agent d'agir comme il l'a fait. Plus précisément, expliquer une action suppose que l'on attribue à l'agent un certain nombre d'états psychologiques qui rendent appropriés le fait d'accomplir cette action. Davidson soutient que connaître la raison d'une action revient à savoir quelle intention l'a suscitée. Cela le conduit à proposer une réduction du concept d'intention à celui de raison motivante d'une action. Searle [29] définit une action intentionnelle comme étant la réalisation des conditions satisfaisant une intention. Les philosophes ont aussi souvent attribué des fonctions cognitives et motivationnelles supplémentaires aux intentions. Il est très généralement admis que les intentions ont le rôle de motivation de l'action. Plusieurs auteurs [20, 4, 3] ont souligné que ce rôle ne se limite pas à déclencher l'action mais à la soutenir jusqu'à son achèvement. On a aussi attribué aux intentions une fonction de guidage dans la production de l'action. La composante cognitive d'une intention pour faire une action A comporte un plan pour faire cette action, c'est à dire une représentation ou un ensemble de représentations spécifiant le but de l'action et les étapes de sa réalisation. C'est cette composante de l'intention, ce plan, qui intervient dans le guidage de l'action. 3.2 Le mouvement La plupart de nos actions fait intervenir des mouvements. Israel, Perry et Tutiya [10] ont remarqué que l'explication de l'action reste incomplète si on ne prend pas en compte les mouvements. Ces auteurs donnent une illustration de cette incomplétude à travers ce qu'ils appellent le problème du faux mouvement. Une action échoue, non pas parce que l'intention est mauvaise, mais parce que le mouvement corporel de l'agent n'est pas approprié. De manière générale, il semble difficile de penser que l'on puisse avoir l'intention de faire une action, si l'on n'a pas la moindre idée du type de mouvement qui pourrait constituer le fait de la réaliser. 3.3 Les objets Brentano définit la marque du mental par l'intentionnalité, les états mentaux incluent un objet en eux-mêmes, vers lequel ils se portent ; la cible issu de l'objectif. Ainsi, tout acte mental correspond plutôt à une relation dont les membres sont, d'une part, l'état mental lui-même et, d'autre part, ce vers quoi il est dirigé. L'objet intentionnel fait partie de la définition même de l'acte mental. En d'autres termes, les états mentaux ne peuvent exister que s'ils sont complétés par autre chose qu'eux-mêmes, c'est-à-dire leur objet (dans le sens de cible). Ils ne peuvent exister que s'ils sorteM d'eux-mêmes. En résumé, l'action est conçue comme un passage, une transformation entre une intention et un mouvement. Une action produit un effet sur un objet, elle est déclanchée au nom de buts, qui apparaissent comme les raisons de l'action. 1.4 4 Ontologie des alertes Du point de vue de la surveillance, les alertes sont les résultats des interactions des actions des utilisateurs du SI avec les entités du SI. L'application de ces théories philosophiques à la modélisation d'alertes consiste à définir l'alerte par les concepts de l'action abordés dans la section précédente. Il est difficile, s'il n'est pas impossible, de pouvoir différencier les actions d'un attaquant d'un utilisateur légitime s'il ne s'agit pas clairement d'une signature d'attaque. Ceci est du au fait qu'une fois l'attaquant à l'intérieur du système, il est vu par le système comme un utilisateur légitime. De ce constat, nous avons étudié la démarche d'un attaquant, pour pouvoir identifier les actions possibles dans un SI. La démarche d'un attaquant englobe les actions de ces deux types d'utilisateurs. 4.1 Démarche d'un attaquant Dans [32,16], les actions entreprises par un attaquant peuvent être organisées en 3 phases distinctes : la collecte d'informations, l'exploitation de ces informations et la métastasies qui représente la propagation de l'attaque dans le système. La collecte d'informations représente la première phase de l'attaque, incluant la détermination des caractéristiques du système cible - comme la topologie du réseauxsystème, le système d'exploitation de l'hôte2 , les applications qui les services exécutés comme FTP, web, etc. Les informations collectées durant la première phase seront utilisées pour déterminer les vulnérabilités des hôtes exploitables à distance - services mal configurés ou non sécurisés. Les méthodes utilisées pour exploiter les faiblesses du système sont variées, mais le résultat final se manifeste par l'exécution d'un processus dans un contexte privilégié, comme l'exécution d'une ligne de commande privilégiée, l'ajout d'un compte ou la découverte d'informations critiques de sécurité comme les mots de passe cryptés, etc. La phase de métastasie se rapporte au processus par lequel un attaquant, après avoir déja compromis un hôte, attaque d'autres parties du système en utilisant les ressources de l'hôte compromis. Il tente d'augmenter son privilège en déployant les mêmes techniques utilisées lors de la phase d'exploitation. Il peut installer un programme qui lui permet d'exploiter le système à distance. Durant cette phase, l'attaquant essaie d'effacer les traces générées durant les phases précédentes en modifiant les fichiers d'audit et d'autres entrées nécessaires sur l'OS (comme la base de registres). Le risque majeur survient lorsque l'hôte est complètement compromis, l'attaquant continuant à l'exploiter alors qu'il est dorénavant très difficile de 2Le terme hôte se réfère à une entité générique du réseau comme un router, serveur, firewall, etc. différencier les actions d'un attaquant des actions d'un utilisateur légitime. La figure 2 illustre la démarche de l'attaquant. Figure 2: La démarche d'un attaquant Nous remarquons qu'il existe des intentions limitées dans la démarche d'un attaquant. Nous pourrons donc nous concentrer sur ces intentions, qu'elles proviennent d'un attaquant ou d'un utilisateur légitime. Seule une recherche des mouvements cachés derrière ces intentions permettent de différencier ces deux classes d'utilisateurs. Dès lors, il devient plus intéressant de modéliser les alertes en terme d'intentions et de mouvements que d'actions. Nous détaillerons dans la suite les intentions dont un SI peut être la cible. 4.2 Les Intentions dans le SI Pour attaquer un SI, un attaquant prépare un plan d'attaque ; chaque étape du plan correspondant à la réalisation d'un but. Il passe d'un but à un autre jusqu'à l'obtention d'un but final. Les intentions sont les buts des actions. Les actions d'un attaquant sont planifiées, la planification E:xigant aussi d'avoir des intentions pour réaliser les actions. La notion d'intention est bien adaptée au processus de corrélation, car la reconstitution des intentions permet de découvrir le plan d'attaque. Nous allons interpréter l'intention vue par le système après la réalisation de l'action. L'étude de la démarche d'un attaquant nous a permis d'identifier 4 intentions d'un utilisateur dans le système : Recon : intention de découvrir et/ou de collecter des informations sur une cible ou un ensemble de cibles du SI. Authentication : intention d'accéder au SI via une procédure d'authentification exigeant un identifiant sécurisé. Cette intention est liée aux alertes décrivant l'accès au SI à travers le service d'authentification (en présentant une identité avec ou non la connaissance d'un secret). Parmi ces alertes nous pouvons citer : - Authentification réussie ou échouée d'un utilisateur ou une erreur sur le service d'authentification - Signatures d'attaques qui ont l'intention d'accéder au SI, - Les alertes des scanners de vulnérabilités qui décrivent la présence de vulnérabilités qui permet d'accéder au SI via l'authentifieur si ces vulnérabilités seront exploitées, Autorization : intention d'accéder à des ressources via une procédure exigenat des drois. Il s'agit des alertes pour lesquelles il y a eu un accès à une ressource via une autorisation ou une tentative d'accès à une ressource du système sans que cet accès ne soit autorisé par des règles préétablies. Parmi ces alertes, nous pouvons citer : Figure 3: La démarche d'un attaquant décrite par les intentions - Exécution ou tentative d'exécution d'une application dans un mode privilégié. - Accès à un fichier protégé par des droits ou tentative d'accès à ce type de fichier. - Utilisation ou tentative d'utilisation de certaines commandes du système réservées à des utilisateurs privilégiés, - changement des droits d'accès à des fichiers sensibles, Systern : intention d'accéder à la disponibilité des ressources. Il s'agit des alertes pour lesquelles des ressources système ont été utilisées sans demander d'autorisation : Information sur l'utilisation de la CPU, Taux d'occupation de la mémoire, information sur les activités d'une application, d'un service. Sur la Figure 3, nous décrivons chaque phase de la démarche de l'attaquant, décrite dans le paragraphe précédent, avec les intentions d'un attaquant dans le SI. Toutes les alertes seront décrites par ces quatre intentions. La sémantique de l'alerte sera liée aux mouvements réalisés par l'attaquant ou l'utilisateur du SI pour accomplir son intention. 4.3 Les mouvements dans le SI La réalisation des intentions s'effectue au travers des mouvements ; comme nous l'avons dit les mouvements représentent les moyens qui permettent la réalisation des intentions. Nous avons identifié 7 catégories de mouvement : Activity : tous les mouvements liés aux activités qui ne changent pas la configuration du SI, Config : tous les mouvements qui changent la configuration, Attack : tous les mouvements liés aux attaques, Malware : tous les mouvements liés aux malwares3 , Suspic:ious : tous les mouvements liés aux activités suspectes détectées par la sonde (c'est la sonde qui le juge un mouvement suspect). Vulnerability : tous les mouvements liés aux vulnérabilités. Information : les sondes peuvent remonter des messages d'alertes qui ne reflètent pas la présence d'action, elles reflètent un état constaté du SI. Sous chacune de ces grandes catégories, il existe des mouvements liés au type d'intention. Notons qu'une intention pourra avoir plusieurs mouvements, par exemple, un accès au SI se traduit par l'ouverture d'une session ou par la configuration d'un compte ou encore par une attaque brute force, nous avons identifié 185 mouvements. 4.4 Les objets du SI Chaque utilisateur a l'intention d'obtenir un gain sur une ressource, chaque mouvement s'accomplit dans cette intention. Toutes les ressources du système, représentent dans notre cas une cible. Les cibles sont des entités logiques utilisateur, données, processus, protocole - ou des entités physiques - composan, équipements, interconnexions. Toute cible est modélisée par un couple (ciblel, cible2) dont la signification varie suivant: l'intention portée par l'alerte. 3Des logiciels malveillants développés dans le but de nuire à un système informatique Dans le cas de l'intention Authentication, le couple (ciblel, cible2) concerne respectivement l'authentificateur et l'authentifié. L'authentificateur représente le système d'authentification utilisé pour accéder au SI et l'authentifié représente le compte qui a ouvert une session dans le SI. Dans le cas de l'intention Autorization, le couple (ciblel, cible2) concerne respectivement le propriétaire de la ressource et la ressource dont les droits ont été utilisés pour y accéder. Dans le cas des intentions System et Recon, le couple concerne respectivement la ressource et un attribut de la ressource, par exemple deux cibles physiques comme (Hote, CPU) ou deux cibles logiques comme (WEB, URL). 4.5 Gain La réussite ou l'échec d'une action sur le système dépend de certaines conditions. Si ces conditions ne sont pas conformes aux règles qui gèrent l'accès au système ou aux ressources du système ou si les informations collectées ne sont pas conformes aux informations environnementales, l'action est un echec (failed). Elle est réussie (success) dans le cas contraire. Le résultat d'exécution d'une action se traduit donc par un gain. Nous voulons faire apparaître ce gain car il exprime la progression d'un utilisateur dans le SI. - 1 gain pour les intentions liées aux mouvements Attack, Malware, Vulnerability : Detected. Nous évitons d'exprimer le gain dans ces cas par un succès, car sémantiquement, le succès d'une attaque représente sa réalisation sans qu'elle ne soit détectée par une sonde de surveillance. De ce fait, le terme Detected est utilisé. - 7 gains pour les intentions liées au mouvement Information: Valid, Invalid, Notify, Expired, Low, Exceeded, Normal pour exprimer l'état des cibles. Les gains sont liés soit aux informations de contrôle des activités des cibles du SI : Valid : un état valide suite à un contrôle, Invalid : un état invalide suite à un contrôle, Notify : une notification sur une cible suite à un contrôle, Ou soit aux informations de contrôle de l'utilisation des seuils sur les cibles du SI E:xpired: dépassement de la durée prévue, Exceeded : dépassement d'un seuil qui n'est pas lié au temps, Low : utilisation basse de seuils, les seuils peuvent être une limite sur des droits, ou peuvent exprimer le manque de privilège d'un utilisateur, Normal : utilisation normale des seuils. 4.6 La sémantique de l'alerte Notre ontologie s'appyue sur quatre classes, Intention, Mouvement, Cible et Gain. Elle définit une relation entre Intention et Mouvement appelée Use, une relation entre Intention et Cible appelée Directed To et une relation entre Intention et Gain appelée Produce. La figure 4 représente une vue de haut niveau de notre ontologie, chaque noeud représente un concept et chaque arc une relation sémantique (un prédicat). L'idée principale de notre ontologie est la suivante : une alerte est une Intention dirigée vers une Cible (cl ,c2), l'Intention utilise un mouvement et elle produit un gain. Figure 4: Sémantique de l'alerte Notre ontologie modélise les activités à surveiller dans le SI avec comme objectif la détection d'intrusion. Elle est spécifiée par le langage OWL (Web Ontology Language) [21] comme langage de représentation de connaissance. Le langage OWL est basé sur la logique descriptive, un sous ensemble de la logique du premier ordre. Contrairement à des langages orientés présentation de l'informations à des opérateurs humains, le langage OWL, est conçu pour le traitement de l'information. Il permet d'exprimer les propriétés de classes équivalentes, d'identité de deux ressources, de différences entre deux ressources, de contraire, de symétrie, de transitivité, de cardinalité, etc. Ainsi, il autorise l'expression de rapports complexes entre des ressources. La figure 5 présente à titre d'exemple l'ensemble des sous classes de la classe Intention, Figure 5: La classe Intention La figure 6 présente une vue de haut niveau de la classe Mouvement. Figure 6: La classe Mouvement Le code suivant est une représentation d'un sous ensemble de l'ontologie en OWL. Il comprend les classes Intention, Mouvement, Cible, Gain et les relations Use, Directed_To, et Produce. Expérimentations effectuées Dans l'objectif de tester notre ontologie, nous avons focalisé nos analyses sur l'exhaustivité de l'ontologie (chaque alerte est couverte par une catégorie) et sur la réduction du nombre d'alertes à présenter à l'analyste de sécurité. Pour nos expériences, nous avons à notre disposition un corpus de 20182 alertes programmées dans 123 sondes différentes. Une caractéristique essentielle de ce corpus est que les alertes proviennent de sondes hétérogènes de par leurs fonctions et de par leurs schémas de nommage. Les sources utilisées sont des logs d'équipements de sécurité, des logs d'audits systèmes, des logs d'audit applicatifs et des logs des équipements réseaux. Le tableau 1 présente les différents types de sondes utilisés et,entre parenthèse, le nombre de sondes par type est précisé. Logs de sécurité Logs Applicatifs Logs Système Logs des 51 sondes) (29 sondes) (22 sondes) équipements réseaux (7 sondes) IDS (5) Serveurs Mail(7) 1Nindows(4) Routeur (1) Firewall(18) Serveur FTP(3) Unix-Linux(14) Switch(1) À ntivirus(9) Serveur Web(3) Autre(4) Console de management (5) À uthertification(8) Serveur de base de données(2) PN(3) Serveur DNS (1) IPS(2) Proxy (7) À ntispam(1) Autres applications (6) Monitoring (5) Table 1: Les types de sondes utilisés Le processus de classification est effectué avant la phase de corrélation, il est effectué manuellement par des experts, il consiste à lire le message de l'alerte brut et: à l'affecter à la catégorie qui décrit sa sémantique. Une catégorie est représentée par le 4-uplets : Intention, Mouvement, Cible, Gain. L'expert doit extraire l'intention de l'action qui a générée l'alerte, le mouvement utilisé pour accomplir l'intention, la cible vers laquelle l'intention était dirigée et le gain liéc à cette intention. La définition des différents mouvements, intentions et cibles à surveiller a rendu l'ontologie flexible et adaptable à chaque source de surveillance. Nous avons pu trouver une catégorie pour chaque alerte. Nous avons utilisé le mouvement "other" dans les catégories de mouvements vulnerability, attack et suspicious afin d'être exhaustif et de pouvoir classifier une alerte qui décrit une attaque encore inconnue. Parmis les 128 mouvements décrit dans notre ontologie, nous avons utilisé que 157 mouvements. Les 28 mouvements manquant existent théoriquement mais ne sont pas surveillés par les sondes impliquée dans l'expérimentation. La classification de ce corpus d'alertes a généré 1734 catégories. Ce résultat est intéressant car nous avons pu réduire le nombre de messages d'alertes à présenter à l'analyste de 20182 à 1734 (soit 8,60%). Prenons l'exemple d'une sonde, utilisée dans cette expérience, correspondant au scanner de vulnérabilités qui possède la plus grande base d'alertes : 10260 alertes. Cette base a été réduite à 390 catégories. Nous avons eu des catégories de différentes tailles, la plus grande regroupe 6627 alertes et qui représentent 32,83% du corpus. Ceci est dû à la surveillance des mêmes mouvements par différentes sondes ou à la présence de ces signatures dans différentes sondes, comme par exemple une signature de type attaque DOS qui est implantée au niveau de tous les IDS. La représentation de ces alertes sous la même sémantique renforce le processus de détection dans un contexte coopératif et facilite la tâche de l'analyste en lui présentant une seule alerte qui reflète la sémantique de 6627. La figure 7 représente un échantillon des distributions des alertes sur les catégories. Figure 7: Classification des alertes Par ailleurs, nous avons eu des catégories unitaires, 732 alertes brutes formant leurs propre catégorie, ce qui représente 42,21%de toutes les catégories et qui ne représente que 3,63%du corpus. La présence de catégories de taille unnitaire peut être expliquée par les points suivants : - Il y n'a qu'une seule sonde parmi les sondes déployées qui remonte ce type d'alerte. Une signature, qui est reconnue par une sonde, ne l'est pas par les autres sondes. - Des erreurs commises par les experts ont engendré la création de nouvelles catégories, elles ne doivent pas existées théoriquement. - L'existence de cibles rarement surveillées augmente le nombre de catégories unitaires, car le mouvement existe plusieurs fois, mais une seule fois pour ces cibles rares. Le résultat obtenu renforce notre proposition de départ qui consiste à déployer des sondes de type différent dans la détection d'intrusion. En effet, la présence de catégories unitaires prouve qu'il existe des activités qui peuvent arriver dans un SI et qui ne peuvent pas générer d'alertes si elles ne sont pas surveillées. Prenont l'exemple de la surveillance du mouvement d'ajout de compte de groupe sur le service d'annuaire LDAP. Il est surveillé par une seule sonde et qui génère la catégorie Rights:Config_Add:LDAP_AccountGroup:Success. Les figures 8 et 9 illustrent les distributions des alertes sur les mouvements pour les différentes intentions. Nous constatons que l'intention System est la plus utilisée, nous constatons également que le mouvement vulnerability et le mouvement attack peuvent avoir tous les types d'intention. On peut remarquer que la catégorie du mouvement suspicious introduite dans notre ontologie est bien nécessaire pour préserver la sémantique des alertes brutes qui reflètent une suspiçion. Ces types d'alertes seront traitées avec les autres par un moteur d'analyse comme par exemple un corrélateur. L'ontologie ne permet pas d'analyser les alerte, son objectif est de préserver la sémentiques des alertes bruts. La catégorie de mouvement Information qui ne décrit pas des actions effectuées dans le SI mais les états des cibles. Ces informations sont remontées par les sondes et seront également prises en compte dans le processus de corrélation. Les proportions des différentes intentions dépendent des sondes déployées et des activités à surveiller par ces sondes. La conclusion que nous pouvons tirer de cette étude est qu'une bonne ligne de défense doit surveiller toutes les intentions visées dans un SI et que la détection coopérative ne doit pas se focaliser sur le nombre de sondes déployé mais sur les intentions et les mouvements à surveiller dans un SI. Ce résultat peut remettre en question le choix de ligne de défense représenté par les sondes à mettre en place pour surveiller un SI. Figure 8: Distribution des Intentions sur les mouvements Figure 9: Distribution des Intentions sur le mouvement Vulnerability Nous avons constaté que la classification manuellement des alertes a engendré des erreurs. Ces erreurs sont liées à : - La perception de l'expert : les connaissances de chaqu expert varient ainsi que leur pratique de l'ontologie. Avec la pratique, l'expert acquiert plus d'expérience qu'avant et le taux d'erreurs diminue, mais nous serons face au mêmes problème avec chaque nouvel expert. - Au non respect de toutes les règles préétablies pour la classification : comme par exemple l'utilisation d'un mouvement qui n'est pas lié à une intention pour décrire une alerte a généré une catégorie qui ne doit pas être théoriquement exister. Nous avons eu 433 alertes mal classifiées de cette manière, ce chiffre est très petit devant la taille du corpus ; il a tout de même généré 43 catégories qui ne présentent pas un sens. Il peut s'agir d'un problème de concentration de l'analyste humain qui pourrait être résolu par des sessions de normalisation de plus courte durée . - Au non respect du grain utilisé pour représenter la sémantique de l'alerte : dans notre modélisation, nous avons défini le même niveau de détail pour chaque type de mouvement suivant les intentions. Nous avons constaté que quelques analystes n'ont pas respecté ce niveau de détail pour exprimer la sémantique de l'alerte. Prenant l'exemple qui exprime que "le mot de passe de l'administrateur de SSH a été accepté", était classifiée en "`Authentication:config_Modify:SSH_password:successm pour une sonde et en mAuthentication:config_Modify:SSH_Admin:success" pour une autre sonde. Le non respect du grain utilisé pour exprimer la sémantique engendre des erreurs dues à l'expression du même sens par deux catégories différentes et augmente le nombre de catégories. Ces erreurs engendrent des risques, comme la classification d'un comportement qui ne présente pas de danger en comportement dangereux - c'est-à-dire un faux positif et la présentation d'un comportement dangereux en comportement normal engendre - un faux négatif. De ce fait, on peut conclure que les mauvaises données engendrent de mauvais résultats même si on applique un algorithme de corrélation efficace pour la détection d'intrusion. Pour éviter ces erreurs, nous devons respecter les règles dictées par la politique de l'ontologie afin de ne pas créer de nouvelles catégories, de définir le niveau de détail pour chaque type de catégorie, de respecter les définitions des intentions et des mouvements pour ne pas engendrer par la suite de faux positifs ou de faux négatifs. Ceci pourrait également être effectué par un processus automatique ou semi-automatique qui gère la tâche de la classification ou qui peut aider l'analyste à prendre une décision dans le cas où il ne peut pas le faire automatiquement. 6 Conclusion et perspectives Dans cet article nous avons développé une ontologie flexible et extensible basée sur la théorie de l'action pour décrire les comportements qui ont eu lieu et qui sont en cours dans un SI. La théorie de l'action nous a permis d'extraire les concepts nécessaires pour modéliser une action observée. Ces concepts sont : l'intention, le mouvement, la cible et le Gain. L'étude de la démarche d'un attaquant et d'un utilisateur nous a permis de dégager les intentions liées au SI et de pouvoir cerner l'ensemble des catégories. Cette ontologie a été développée avec l'identification des différents mouvements des utilisateurs légitimes, des attaquants et du système. Nous avons ensuite vérifié notre ontologie sur un corpus de 20182 alertes issues de sondes hétérogènes. Nous avons pu réduire le nombre de messages d'alerte destinées à l'analyste de 20182 à 1734. Cette ontologie peut être appliqué dans un contexte de détection d'intrusion coopérative car elle permet l'intéropérabilité entre les diffétentes sondes et le traitement automatique de la sémantique de l'alerte par des programmes automatiques. La détection d'intrusion sera donc efficace dans le cas de coopération entre sondes pour la surveillance des intentions et des mouvements. Nous avons identifié des erreurs et des risques liées à l'application de l'ontologie par des experts. Enfin, les prochaines étapes de notre travail consistent à nous diriger vers le développement des algorithmes pour la classification automatique et semi-automatique en se basant sur les techniques d'apprentissage tout en exploitant les relations sémantiques entre l'intention, le mouvement, la cible et le gain pour aider l'analyste dans le processus de classification afin de surmonter les risques liés à la classification manuelle. Partie II - Spécification générale de la normalisation ExaProtect. 1 Processus de modélisation L'idée de la modélisation ExaProtect est de modéliser avec les mêmes concepts toutes les activités observables par un système de surveillance. Ces activités observables deviendront les modèles de référence. Les activités observables sont difficiles à détecter. Pour ce faire, nous avons étudié les besoins en terme de « données en entrée » qu'utilise un système de surveillance. Nous nous sommes intéressés : à la définition théorique d'une alerte pour classer les alertes : notion de concept ontologique, à ce que représente une alerte par rapport aux différents usagers du système : notion de progression, 1.1 ontologie Une alerte du point de vue théorique est le résultat de l'observation d'une action ou d'un état faite par une source. Généralement, une action s'exprime au travers de cinq concepts : le l'objectif (INTENTION) dirigé vers une cible (TARGET TYPE, TARGET DETAIL), en utilisant un mouvement classé affecté à un type d'activité (ACTIVITY qui en définitive produit un résultat (RESULT). Le schéma de la figure 10, ci-dessous. Figure 110. Description de l'événement Afin d'identifier avec précision l'ensemble des activités canoniques ou de référence, que se doit de surveiller un système de surveillance, nous avons utilisé l'ontologie ci-dessus conçue par ExaProtect (figure 10). L'ontologie est fondée sur le fait que tout évènement résultant de l'observation d'une activité. Chaque activité s'inscrit dans une logique appartenant d'attaque, d'usage, d'administration ou encore de fonctionnement d'un système. La première classification réalisée résulte de l'observation que chaque évènement reflétant et décrivant un comportement. C'est pourquoi, notre ontologie est une ontologie comportementale. Dans le domaine de la surveillance, nous cherchons à surveiller ces 4 types de comportements ou d'activités de référence : Les activités d'usage normal par un usager Les activités d'usage normal par le système Les activités d'administration concernant l'usager ou le système Les activités illégitimes et anormales concernant l'usager ou le système 1.2 Processus de modélisation ExaProtect Avec les 5 concepts de l'ontologie, les modèles Exa permettent la représentation abstraite de 2 types d'informations observées par les sources de surveillance : les informations qui donne des informations sur les comportements, modélisables avec les concepts de modélisation de « mouvement / intention /résultat », - les informations qui donnent des informations sur les états des cibles du SI avec le concept de modélisation « d'état du système ». Nous allons définir les deux types de modèles qui en découlent : modèle d'action et modèle d'information. 1.2.1 Classification des actions Il s'agit de modéliser les informations sur les comportements. De cette manière, l'ontologie distingue : Pour les activités d'un usager=> o AUTHENTICATION ACTIVITY o RIGHTS_ACTIVITY- Pour les activités du système => o SYSTEM_ACTIVITY Pour les actions d'administration => o AUTHENTICATION _ CONFIG o RIGHTS_ o SYSTEM_ CONFIG - Pour les activités illégitimes et anormales => o AUTHENTICATION_ ATTACK o AUTHENTICATION_ SUSPICIOUS o AUTHENTICATION_ MALWARE o RIGHTS_ ATTACK o RIGHTS_ SUSPICIOUS o SYSTEM ATTACK o SYSTEM _ SUSPICIOUS o SYSTEM _ MALWARE La caractéristique d'un comportement du point de vue d'un système de surveillance est la progression que permet l'action par rapport à la criticité des assets. Nous avons par conséquent associé au concept de RESULTAT une notion de gain évaluant ainsi la progression des comportements au travers des activités remontées. Par exemple, le démarrage d'un service constitue un gain de disponibilité pour le système, l'authentification d'un utilisateur constitue un gain d'accès pour l'utilisateur, la détection d'une attaque constitue un gain de « détection » pour le système, etc... 1.2.2 Classification des informations Nous avons distingué un ensemble regroupant les évènements dont l'objectif est de décrire les états du système comme par exemple le dépassement de seuil, l'invalidité d'informations ou encore la vulnérabilité du système. Nous avons choisi de décrire les états du système en fonction des différentes activités, ce qui, pour modéliser les états du système, donne l'expression : - les informations concernant les activités d'un usager => o AUTHENT1CATION_INFORMATION o AUTHENTICATION_ VULNERABILITY o RIGHTS INFORMATION o RIGHTS_ VULNERABILITY - les informations concernant les activités du système => o SYSTEM INFORMATION o SYSTEM_ 1.3 Les modèles Exa Un modèle Exaprotect n'est autre qu'une phrase générique et simple faisant appel aux 5 concepts fondamentaux ; lors du processus de normalisation, il suffira d'instancier les 5 concepts pour transformer l'évènement en alerte. Autrement dit, cette alerte constitue une instance du modèle. La sémantique de l'évènement doit rester inchangée après transformation et elle devient commune à l'alerte instanciée. Des évènements de même sens mais dont les sources de surveillance ont utilisé des termes propres auront le même modèle et ses 5 concepts identiques. Le langage de description utilisé est spécifique à ExaProtect et comporte une définition lexicale, syntaxique et sémantique de chaque modèle. La modélisation ExaProtect est elle-même définie par un langage de description développé dans le chapitre « Langage ExaProtect ». Les modèles Exa existent sous 2 formes : les modèles d'action et les modèles d'information. 1.4 Modèles d'action Comme nous l'avons présenté en introduction., les modèles ExaProtect ont pour objectif la modélisation de toutes les activités possibles susceptibles de se dérouler au sein du SI. Afin de détecter de manière exhaustive et nette l'ensemble de ces activités, nous avons utilisé une ontologie. Il a pu être classifié de cette manière des activités qui reflètent le comportement des usagers normaux, anormaux, des administrateurs ainsi que ceux du système. Chaque action peut s'exprimer selon le modèle abstrait suivant : « Le mouvement M sur une cible C a un résultat R pour une intention d'accès I » Cette phrase s'appuie sur 5 concepts et devient une expression structurée en 5 champs : CONCEPT Défintion INTENTION Objectif détecté par l'observation du moyen et de l'activité, Nature du mouvement qui précise l'intention Moyen employé pour atteindre l'intention Cible et Attribut de la cible visés par l'intention ACTIVITE MOUVEMENT CIBLE 1,, CIBLE 2 RESULTAT Gain ou perte obtenu suite à l'activité exercée Valeur de l'état du système lorsqu'il s'agit d'une observation informative Chaque évènement sera une instance de cette phrase selon les valeurs mouvement, cible, résultat, intention. 1.4.1 Intention L'intention est le résultat de notre étude sur la démarche des différents utilisateurs d'un SI, qu'ils soient normaux, anormaux ou suspicieux. L'intention modélise la raison pour laquelle les actions sont déclenchées. Elles permettent donc d'apporter une classification des différents mouvements. Nous pouvons réaliser un même mouvement avec des intentions différentes et à contrario nous pouvons aussi adapter, modifier un même mouvement selon l'intention. Nous avons identifié 3 intentions qui correspondent chacune à la démarche d'un usager d'un système quel qu'il soit : 1 L'accès au SI en utilisant l'authentification (Authentication) 2 L'accès au Ressources en utilisant les droits ou autorisations (Rights) 3 L'accès au Système en utilisant sa disponibilité (System) Ces 3 opérations sont séquentielles. Nous pensons que pour progresser vers une cible, tout usager du SI devra utiliser des actions appartenant à ces 3 catégories. Dans nos travaux futurs nous mesurerons et surveillerons ainsi la progression des usagers par le biais du type d'action remonté. 1.4.2 Mouvement 1.4.2.1 Définition Le MOUVEMENT représente le moyen utilisé pour aboutir à l'intention. Le MOUVEMENT est lié à l'auteur supposé » de l'action. Le MOUVEMENT est dirigé contre une cible et reste fortement lié à celle-ci : un MOUVEMENT est dirigé contre une cible et guidé par une intention. Le concept MOUVEMENT est en relation avec le concept « ACTIVITY ». ACTIVITY est le concept qui permet de préciser MOUVEMENT et d'instancier le fait que le MOUVEMENT est réalisé dans le cadre d'une fonction d'usage normal, d'administration, d'attaque, etc... Là encore, nous avons identifié une cinquantaine de type d'activités employées par les systèmes ou les usagers ou les attaquants. Certaines sont spécifiques aux objectifs d'autres sont partagées. Nous montrons ci-dessous quelques exemples de mouvements : =>Spécifiques aux activités de configuration et commun aux 3 intentions A out/su ression/modification Authentication Config Add PKI Certificate failed Authentication Config Add PKI Certificate success Authentication Config Add WEB Account success Authentication Config Add SysAuth Account success Authentication Config Add SysAuth Account failed Rights Config Add OS AccountGroup failed Rights Config Add OS AdminGroup success Rights Config Add LDAP AccountGroup success System Config Add Audit LogFile success System Config Add Audit Cluster success Authentication Config Delete PKI Certificate success Rights Config Delete OS AccountGroup success Rights Config Delete OS AccountGroup failed System Config Delete Cluster Component success System Config Delete Host Disk success System Config Delete Firewall ACL success System Config Delete OS ConfFile success =>Spécifiques aux activités d'usage et du SYSTEM envoi/réception System Activity Receive ICMP Request Success System Activity Receive OS Packet error System Activity Send FTP File Success System Activity Send OS Message error System Activity Send ICMP Request error =>Commun aux activités d'usage, d'attta- es AUTHENTIFICATION s-écifi- e à l'intention ouverture de session/bruteforce Authentication Attack BruteForce MAIL detected Authentication Attack BruteForce SysAuth Password detected Authentication Suspicious BruteForce TELNET Account detected Authentication Suspicious BruteForce Firewall detected Authentication Vulnerability BruteForce Chat Password detected Authentication Vulnerability BruteForce MAIL detected Authentication Activity Login SysAuth Anonymous failed Authentication Activity Login SysAuth Account failed Authentication Activity Login FTP Account success Authentication Activity Login SysAuth Account success Authentication Activity Login SSH Admin success Authentication Activity Login SSH Account failed =>Spécifiques aux activités d'usage et du SYSTEM démarrage/arrêt System Activity Down APC Temperature error System Activity Down Firewall success System Activity Down Firewall Interface success Le MOUVEMENT est du point de vue des systèmes de surveillance extrêmement précieux car c'est le fait que l'on observe : il est vrai, évaluable et contrôlable. Il est notamment possible de l'évaluer face à la criticité et au danger qu'il représente. C'est pourquoi nous avons choisi de modéliser l'ensemble des MOUVEMENTs possibles dans le SI, dans le but de mettre en oeuvre un système de surveillance basé sur la surveillance des MOUVEMENTs. Nous avons relié chaque modèle de MOUVEMENT à différents profils d'utilisateur, et plus précisément à leurs étapes. Ceci diffère des mécanismes classiques qui tentent de modéliser les effets sur les états du système. Ces modèles sont reliés par des graphes d'état et forment des scenarii appris au préalable. Les mécanismes de détection alertent l'analyste en cas de changements d'état. En outre, la surveillance et la détection par états du système entraînent une modélisation lourde alors que les modèles de MOUVEMENTs proposés dans ExaProtect sont peu nombreux : nous en avons recensé une centaine. Ces points forts vont permettrent aux algorithmes de traiter les logs bruts en nombre réduits ; avec un haut niveau d'abstraction et une modélisation comportementale. 1.4.2.2 Granularité des modèles Néanmoins, la difficulté réside sur le choix des MOUVEMENTs à modéliser et de leur grain. Par exemple, lors de l'ouverture de session d'un utilisateur, le MOUVEMENT qui intéresse notre système de surveillance est le gain ou l'échec rencontré lors de l'accès au SI. Le log brut fournit une phrase détaillant ce fait observé et en donnant la cause du refus. Voici un exemple d'un échec d'ouverture de session liée à une méthode d'authentification de type CHAP : Astaro_v5.rulesçCHAP authentication failed Notre système de surveillance ne s'intéresse pas directement aux causes de l'échec. Dans le cadre de la surveillance basée sur les MOUVEMENTs, nous voulons modéliser qu'un utilisateur a échoué dans son ouverture de session sans en connaître la cause : Authentication Activity Session SysAuth Account failed 1.4.3 Résultat Chaque action qui se déroule induit un résultat qui dans notre ontologie est évaluée en fonction de son apport vis-à-vis de la progression de l'usager sur la cible. Nous distinguons 2 Résultats : Gain : l'usager progresse sur la cible, Echec : l'usager ne progresse pas sur la cible 1.4.4 ,Activité L'activité permet de décrire la nature du MOUVEMENT utilisé pour atteindre l'intention et le résultat. Dans certains cas de modélisation nous utilisons le terme MOUVEMENT qui inclut la notion d'activité et qui forme un couple au sens de la modélisation. 1.4.5 Modélisation A l'aide de ces concepts nous pouvons modéliser les comportements en une phrase à un niveau d'abstraction élevé : « Le MOUVEMENT M sur une cible C a un résultat R pour une intention d'accès I » Authentication J Activity Login SSH Admin success Ssh.rules-SSH Remote root loqin Fortiqate nmap-User admin loqin successfullv from SSH Le MOUVEMENT d'ouverture de session d'un compte Administrateur du service SSH a réussi pour l'intention « acces par authentification ». Account Mcafeeintrushield.ma-FTP : Login Failed 0x40505600 Aix.rule-ftp: login failed Authentication Activity Login FTP failed Le MOUVEMENT d'ouverture de session d'un compte du service FTP a échoué pour l'intention « accès via authentification ». Authentication Activity Backup PKI Credential Security_wmi.map-Certificate services backup completed Le MOUVEMENT de sauvegarde des credentiels du service PKI a réussi pour l'intention « accès via authentification » Ri hts Activity -1 Gain OS Account System_wmi La difficulté est le langage qu'utilisent les sources de surveillance pour exprimer un mouvement donné. Dans le cadre de notre normalisation DETECTER UN MOUVEMENT c'est NORMALISER. Il est important en outre que la phase de normalisation respecte et préserve le sens initial de l'évènement (log brut). Le tableau ci-dessous montre que la connaissance de nos concepts peut permettre ou non une modélisation. La cas 1 où l'expert détecte le mouvement et la cible 2 permet de normaliser. Les cas 2,3 et 4 où l'expert ne détecte pas le mouvement ne permet pas la modélisation. Notre outil va donc permettre d'assister l'expert pour lui permettre de détecter plus de concept dans l'évènernents qu'il lit afin de reconnaître au mieux le modèle Si l'expert a la Connaissance de :4' Alors :4' Mouvement Intention Cible 1 Cible 2 Résultat Modélisation 1 Oui Implicite Implicite Oui Oui Oui 2 Non Plusieurs Plusieurs Plusieurs Oui Non 3 Non Non Oui Oui Oui Selon la cible 4 Non Plusieurs Oui Plusieurs Oui Non Plusieurs Plusieurs Plusieurs Plusieurs Oui Non Nous ccnstatons que de 4 cas ne permettent pas une modélisation implicite.. L'extraction du MOUVEMENT n'est pas toujours possible ou précise, l'expert doit utiliser d'autres « points d'entrée » pour extraire la sémantique du log brut : en cas de difficulté pour identifier le MOUVEMENT, il va extraire l'intention, la cible ou le résultat. 3.2.2 Approche pragmatique de la modélisation de la connaissance experte Nous avons observé que certaines cibles n'existent que pour certaines intentions. Ainsi, la connaissance de la cible apporte la connaissance de l'intention. C'est le cas de la cible « compte utilisateur » dont l'utilisation s'utilise avec l'intention « authentification » ou de la cible « groupe » dont l'utilisation est exclusivement avec l'intention « rights ».Voici quelques exemples statistiques mettant en valeur le rapport occurrences de cibles/ intention. Sur 12 logs contenant l'ex ression « anon mous », Intention Nombre Authentication Sur 28 logs contenant l'expression « memoiy », 28 sont modélisées en intention « system» et sont soient des informations soient des attaques Intention Normbre 28 System 100% Sur 135 logs contenant l'ex ression « user » : Intention Nombre Sur 40 logs contenant l'ex ression « - rou. » : Nombre - Intention Rights 40 100% Authentication Sur 59 logs conten Intention Nombre 2 Authentication activi 4 Authentication information 1 Authentication vulnerabili 1 Rie hts activi 3 Rights_conf - 3 Rights_vulnerabili 15 System activi 6 System confie 6 System,_attack 7 System information 8 System vulnerabili 3 System,_suspicious Bilan : notion de cible implicite et explicite Nous distinguerons les cibles qui vont permettre de définir l'intention, l'activité ou le mouvement, des cibles qui permettent plusieurs choix des cibles démunies de toute sémantique de mouvement. Les cibles dites implicites vont permettent de déduire le mouvement sans ambiguïté, Les cibles dites explicites vont permettre de restreindre l'ensemble des possibilités à une liste restreinte. L'identification de ce type de cible est disponible dans la partie Il du document qui indique la liste des cibles par mouvement. 3.3 Processus de normalisation Le but du processus de normalisation est d'instancier un modèle Exa prédéfini pour en générer l'alerte correspondant en fonction des valeurs (instances) de chaque concept. Par exemple, le MOUVEMENT « ouverture de session » dans une intention « d'authentification » s'instancie avec les utilisateurs, les services d'authentifications et le résultat : succès ou échec de l'ouverture de session. Voici un exemple de modèles instanciés : 3.3.1 Approche pragmatique du processus de normalisation Comme nous l'avons précisé ci-dessus, les modèles ExaProtect sont une représentation abstraite des MOUVEMENTs observés dans un système d'information et une des difficultés réside dans le choix des MOUVEMENTs utilisés pour atteindre les cibles et accomplir l'intention qui a motivé ce MOUVEMENT. Le langage ExaProtect est là pour contraindre l'analyste à l'extraction des seuls 5 concepts en lui imposant des valeurs lexicales et syntaxiques. un ensemble de modèles Exa déjà prédéfinis et basés sur les MOUVEMENTs à l'aide des concepts retenus. La tâche de l'expert de sécurité consiste en la transformation d'un log brut en détectant les différents concepts qu'elle porte. Par exemple pour le log rastaro v5 rulesçCHAP authentication failed L'expert va tenter d'extraire : Intention= Authentication MOUVernent---AuthenticationActivity_Login Instances de Cible 1 = choix dans la liste des services d'authentifications définis pour Authentication_Activity_Login Instances de Cible 2 = choix dans la liste des utilisateurs définis pour Authentication_Activity Login Instances de Résultat = choix dans la liste résultat : failed/success Authentication Activity Login SysAuth. - Account ' failed Authentication Activity Login SysAuth Account success Authentication Activity Login Database Account faileid Authentication Activity Login FTP Account failed Authentication Activity Login FTP: Account success Authentication Activity Login PKI Crèdential failed Authentication Activity Login SysAiith Account failed Authentication Activity Login SysAuth Account failed Authentication Activity Log in SSH Admin , failed Le langage ExaProtect permet en outre de préserver la normalisation réalisée par l'expert d'une autre difficulté qui est le niveau de détail. Un des souhaits de la normalisation de ExaProtect a été d'apporter un niveau d'abstraction élevé avec un fort pourvoir de généralisation. Il s'agit de la notion de grain. Par exemple, en reprenant l'exemple précédent sur astaro_v5 ruleseHAP authentication failed `Authentication Activity Login sAuth Account failed Si à la place de la cible SysAuth_Account, la valeur Account_Method avait été retenue, nous aurions à la fois modélisé le motif du refus et l'échec de login. Authentication Activity Login Ac otnt Or si l'on considère le log brut suivant, bluecoat_system rutes-Login denied la modélisation sera une simple traduction d'un échec d'authentification : la cause n'est pas indiquée. Authentication Activity Login SysAuth Account failed Bilan Du point de vue du système de surveillance, ces 2 alertes ont la même signification, donc elles doivent appartenir au même modèle. 3.3.2 Processus de normalisation explicite et implicite de la connaissance 3.3.2.1 Processus de normalisation de base Nous présentons dans ce paragraphe, le processus de normalisation simple lorsque l'expert reconnaît et détecte le mouvement. Lorsque l'expert observe un évènement et que l'on doit associer la catégorie correspondante, la démarche suivie par l'expert est la suivante : Figure 15: Méthodologie pour la normalisation des évènements Exemple La première étape de l'expert de sécurité est d'extraire le MOUVEMENT que ce log brut exprime. Par exemple, le log brut « User admin login successfully from SSH» permet sans ambiguïté de modéliser un MOUVEMENT d'ouverture de session (login). De même il est facile d'extraire le résultat (success) et les cibles admin et SSH. L'extraction du sens du log brut va permettre de modéliser le log brut « User admin login successfully from SSH» en : Authentication Activity Login S&IAdmil success La démarche suivie par l'expert pour extraire la sémantique a été la suivante : telethed failed Figure 16: Démarche de l'expert pour la normalisation Cependant, certains logs bruts sont imprécis et requièrent de procéder différemment. Le tableau ci-dessous montre que l'expert doit détecter ou posséder certains concepts pour modéliser et que l'absence de l'un ou l'autre concept ne permettra pas de modélisation (cas 1,2,3). On observe que l'absence de la connaissance de « MOUVEMENT » rend difficile la modélisation : 3.3.2.2 Processus de normalisation de implicite Lorsque l'on peut déterminer le mouvement avec la connaissance de la cible, le processus de normalisation est dit implicite. 3.3.2.3 Processus de normalisation de base Lorsque l'on peut déterminer une liste de valeurs possibles à partir de 'lun ou l'autre concept, le processus de normalisation est dit explicite. 3.3.2.4 Schéma globale du processus d'extraction dies connaissances Figure 17 3.3.3 Exemple de l'application du processus de normalisation explicite 1- Le champ main OBJECTIF : Question : Quel est l'objectif visé dans le SI avec cette activité ? 1) est ce l'accès au SI via une authentification ? 2) est ce l'accès aux ressources via les droits ou, 3) est ce la disponibilité du SI ? La réponse doit être l'une des valeurs : o Autentication : si l'activité vise les entrées sorties au SI via un authentifieur o Right : si l'activité vise I'accés aux ressources privilégiées o System : si l'activité vise l'utilisation des ressource via la disponibilité du système. 2- Le type d'objectif : Question : Quel est le type d'objectif ? 1) est ce une attaque ? 2) est-ce un malware 3) est-ce une suspicion ? 4) est-ce une information ? 5) est-ce une vulnérabilité ? 6) est-ce une configuration ? 7) ou est-ce une activité normale qui ne change pas la configuration du SI ? La réponse prend l'une des valeurs suivantes : o Attack : Si l'événement porte sur une attaque détectée o Malware : si l'événement porte sur la détection d'un Malware o Suspicious : si l'événement porte sur la détection d'une activité suspecte o Information : si l'événement porte une information sur l'état d'une cible o Vulnerability : si l'événement porte sur la détection d'une Vulnérability o Config : si l'événement porte sur configuration d'une cible o Activity : si l'événement porte sur une activité normale qui ne rentre pas dans les autres cas 3- Le champ ACTIVITY :et MOUVEMENT Question : Quel est le moyen ou la méthode utilisée? La réponse dépend en premier lieu du type d'objectif, elle peut être : o Control ou Threshold : Si l'événement origine décrit un état (un état est une observation en général statique du système), ces valeurs sont exclusivement associées à la catégorie Information o Si l'objectif est une attaque ou une suspicion ou encore un malware, alors ACTIVITY décrit le type d'attaque (ou de Malware ou de Suspicion) o Si l'objectif porte sur une vulnérabilité (vulnerabiltiy) alors ACTIVITY décrit le type de vulnérabilité. o Si l'objectif porte sur une configuration (config) alors ACTIVITY décrit la natur de la configuration : modification, ajout, etc.... o Si l'objectif porte sur une activité normale (activity) alors ACTIVITY décrit sa nature suivant le sens porté par l'événement. Pour une activité normale, la réponse dépend en second lieu du champ Main Objectif, elle peut être : o Si le Main Objective est AUTHENTICATION :Session, disconnection, o Si le Main Objective est RIGHTS : Gain, o Si le Main Obvjective est SYSTEM Connexion, forward, startup, etc... 4- Le couple (TARGET TYPE,TARGET DETAIL) : Les questions concernant la cible sont : a) Quelle est la cible visée par cette activité ? b) Quelle est la cible sur laquelle porte l'information s'il s'agit s'une information u d'une vulnérabilité ? La réponse peut être : o Target Type et Target Detail prendra les valeurs remontées dans l'événement, elles doivent respecter ce qui est décri ci-dessus (section 2.c) 5- Le champ RESULT : Question : Quel est le résultat de cette activité ? La valeur de Result doit respecter ce qui était décrit ci-dessus (section 2.d) Elle exprime un résultat sous forme de gain (success) ou d'échec (failed) s'il s'agit d'une activité, Elle exprime un résultat descriptif s'il s'agit d'une information comme un dépassement de seuil ou une information invalide. f5-bigip.rulesçNode detected down ISystem Activity Don Hast success iwss perf.map HTTP CPU % Utilization ;zystem Information Threshold Hast CPU exceeded 3.3.4 Exemples d'application Figure 18: Exemple d'application 3.4 Interprétation de l'alerte normalisée La procédure de normalisation s'adresse à l'analyste de sécurité qui doit interpréter une alerte Exa (un modèle) et comprendre la signification de l'alerte qui lui parvient. Pour interpréter une alerte normalisée on se pose les questions en respectant l'ordre suivant : Figure 19 a,b,c: Interprétation d'un évènement normalisé Partie III - Spécifications détaillées de la normalisation ExaProtect. Cette seconde partie détaille l'ensemble des concepts abordés en partie I. 3.5 Le coeur du présent document : l'outil de normalisation La démarche de l'analyste va donc être adaptée à la connaissance qu'il réussit à extraire du log brut et à la connaissance préalable des règles de normalisation. Ce document regroupe et définit les politiques de classification implantées dans notre outil pour chacun des modèles ExaProtect. Il reflète la démarche que doit suivre l'expert de sécurité pour normaliser les évènements en respectant : les aspects lexicaux, syntaxiques et sémantiques du langage ExaProtect, les concepts existants sans en ajouter de nouveaux qui modifieraient l'intégrité des modèles retenus, en respectant notamment la notion de grain. L'usage de modèles de MOUVEMENT existant Le tableau ci-dessus a montré comment se complexifie le raisonnement en fonction de la connaissance de concepts ou de l'absence de connaissance. Les cas 2,3,4,et 5 posent des difficultés pour normaliser un évènement. Il est clair qu'il devient essentiel d'apporter des contraintes pour normaliser. Néanmoins, la spécificité de chaque modèle requiert de proposer des règles pour chaque concept. Le tableau ci-dessous explique la façon dont est décrit un modèle incluant sa politique de classification. Figure 20 1 Définition des Intentions (Objectifs) L'intention caractérise ce que l'on peut comprendre comme objectif dans l'accomplissement de l'activité. Elle doit ensuite être enrichie du mode et du moyen utilisé pour accomplir l'action observée par la source de surveillance. Généralement, la Cibles est au coeur de toutes les actions d'un usager. Nous avons identifié trois types d'accès aux Cibles : 1. L'accès au SI en utilisant l'authentification 2. L'accès au Ressources en utilisant les droits ou autorisations 3. L'accès au Système en utilisant sa disponibilité.. AUTHiENTICATION Oblentit AUTH ENTICATION Contexte : Racine Contexte:. 711-51«^11MISIAIIM aeMS. Mots-Cteez '6,0118«61,01 Définition WEIMODAMMOMIt L'authentification est une activité d'accès au SI (d'entrée/sortie) qui se réalise TOUJOURS sous le contrôle d'un service d'authentification chargé de filtrer sur des critères précis l'entrée, le refus ou la sortie d'un utilisateur. Les différentes activités d'authentification que l'on peut modéliser dans le système d'information seront : une activité d'usage pratiquée par un utilisateur : AUTHENTICATION_ACTIVITY une activité de configuration du service d'authentification comme la création de compte, le port écouté, etc... : AUTHENTICATION_CONFIG une activité de contrôle réalisée par un tiers : AUTHENTICATION_IN FORMATION une activité de contrôlé liée à la sécurité destinée à relever les vulnérabilités des systèmes, : AUTHENTICATION_VULNERABILITY des activités suspicieuses ou agressives pour pénétrer le SI en tentant de violer la disponibilité, l'intégrité ou encore la confidentialité du système. Nous distonguons 3 catégories : AUTHENTICATION_ATTACK, AUTHENTICATION_SUSPICIOUS, AUTHENTICATION_MALWARE. Régtea MAA"AlSellaMeM1 .9"Aleseeeeenamenes. Toute activité contrôlée par un service d'authentification d'un utilisateur sur un critère de type politique, mot de passe, certificat ou credential (key...). Interdite Toute activité contrôlée par un simple service de filtrage qui ne s'exerce pas sur un compte utilisateur mais sur un autre critère comme une adresse IP, une extension de fichier, ou autre FaireAmis SYSTEM_FORWARD-SYSTEM_CONNECTION Résultats z. 3états sont envisageables pour l'authentification SUCCEtei Succès dans l'activité d'authentification Failed : Echec dans l'activité d'authentification Elle> Concerne une erreur sur le service ou sur le compte ou sur les attributs du compte Detactad : Concerne la détection d'une vulnérabilité, d'une action suspicieuse ou agressive Invaitd, veld, natify Concerne le contrôle d'une activité non-conforme, conforme ou notifiée Cillait.* a cf Deacrtiatton des Oates mur l'authentification Cibka Le service d'authentification Le serveur qui héberge ce service Cibles 2 Utilisateur ou compte utilisateur qui va solliciter le service Attributs du compte comme le password. RIGH1rS Oblectitz RIGHTS Contexte : Racine Contexte: Mots-Cies:: D finition elIMMIMMASIMM- Les PRIVILEGES ou RIGHTS est une activité d'accès aux ressources du SI qui se réalise TOUJOURS sous le contrôle d'un service dépendant en général de l'OS chargé de filtrer sur des critères précis l'accès, le gain ou le refus d'accès d'un utilisateur ou d'u groupe d'utilisateurs à une ressource. De la même manière que pour AUTHENTICATION, nous aurons les catégories d'activités suivantes : une activité d'usage pratiquée par un utilisateur : RIGHTS_ACTIVITY une activité de configuration du service d'authentification comme la création de compte, le port écouté, etc... : RIGHTS_CONFIG une activité de contrôle réalisée par un tiers : RIGHTS_INFORMATION une activité de contrôlé liée à la sécurité destinée à relever les vulnérabilités des systèmes, : RIGHTS _VU LN ERABILITY des activités suspicieuses ou agressives pour pénétrer le SI en tentant de violer la disponibilité, l'intégrité ou encore la confidentialité du système. Nous distonguons 3 catégories : RIGHTS_ATTACK, RIGHTS_SUSPICIOUS, RIGHTS_MALWARE. Règles La modélisation de tout accès sur une ressource via l'affectation ou l'utilisation de droits utilisateurs ou de groupes contrôlés par un service d'accès sera dans la catégorie RIGHTS. Nous entendons ici par ressources l'ensemble des fichiers, répertoires, données des utilisateurs. Lorsqu'il s'agit de ressources liées à la gestion du système comme l'audit, le management ou la sécurité, les accès sont gérés dans la catégorie SYSTEM. Par exemple le gain d'accès à une donnée utilisateur s'exprime dans RIGHTS ACTIVITY_GAIN.OS_Data.SMeee alors que la gain d'accès à un fichier de configuration dans SY-§TEM_ACTIVITY_READ.OS_Conffile.success. Interdite Toute activité contrôlée par un simple service de filtrage qui ne s'exerce pas sur une ressource Tout accès contrôlé via un service d'authentification. Fast. Arnis AUTHENTICATION_SESSION, SYSTEM_READ, SYSTEM_WRITE, -SYSTEM_CONNECTION SUCCeetz: Succès dans l'accès aux ressources Failed Echec dans l'accès aux ressources Ems : Erreur sur le service ou sur la ressources ou sur les attributs des ressources Getected Concerne la détection d'une vulnérabilité, d'une action suspicieuse ou agressive Invale valid, natal, Concerne le contrôle d'une activité non-conforme, conforme ou notifiée a Cibles pour cc MGHTS » Cite« Service qui filtre les accès et qui gère les droits de utilisateurs ou des groupes. Mies ;a Droits, groupe, utilisateurs Attributs SYSTEM Obleolif: Contexte : Racine Contexte.: ASARIODAMIPMMIale Mots--C tes: Définition SYSTEM modélise une activité d'accès au système via la disponibilité des ressources De la même manière que pour AUTHENTICATION et RIGHTS, nous aurons les catégories d'activités suivantes : une activité d'usage : SYSTEM_ACTIVITY une activité de configuration du système comme la configuration d'un composant, etc... : SYSTEM_CON FIG une activité de contrôle réalisée par un tiers : SYSTEM _INFORMATION une activité de contrôlé liée à la sécurité destinée à relever les vulnérabilités des systèmes, : SYSTEM_VU LNERABILITY des activités suspicieuses ou agressives pour pénétrer le SI en tentant de violer la disponibilité, l'intégrité ou encore la confidentialité du système. Nous distonguons 3 catégories : SYSTEM_ATTACK, SYSTEM_SUSPICIOUS, SYSTEM_MALWARE. Règles 111AAMERRINMIMe 11.1^511MMMOSSIMAI, La modélisation de l'accès sur une ressource système quel qu'en soit le type est dans SYSTEM.. Nous entendons ici par ressources l'ensemble des fichiers, répertoires, données système comme un fichier de configuration, un répertoire système, une application, un processus, une commande. interdite z Toute activité sous contrôle de l'authentification ou de la gestion droits Faux.Amis Success : Succès dans l'accès aux ressources Faite Echec dans l'accès aux ressources &far : Erreur sur le service ou sur la ressources ou sur les attributs des ressources Getected Concerne la détection d'une vulnérabilité, d'une action suspicieuse ou agressive lnvalid, valid, natife SYSTEM Concerne le contrôle d'une activité non- conforme, conforme ou notifiée Cabales Cibles 'mur « SYSTEM » eibieS Service ou protocole ou équipement ou application ou exécutable Cibles a Attributs ou données ou composants du système 2 Définition des Activités (ACTIVITY) : ACTIVITY Il exprime pour cette partie de la structure ce que l'utilisateur a fait ou est en train de faire et qui produit des alertes dont l'objectif est de gagner la cible citée. L'auteur réalise son action sans changer au préalable le système. CONFIG Config : l'objectif porte sur la configuration d'une cible L'auteur réalise son action sans changer au préalable le système. INFORMATION l'objectif porte sur une information. ATTACK l'objectif porte sur une injection d'attaque sur une cible MALWARE l'objectif porte sur un malware qui infecte une cible SUSPICIOUS l'objectif porte sur une suspicion VULNERABILITY l'objectif porte sur une vulnérabilité 3 Définition des Activités (MOUVEMENTs) Présentation => Pour comprendre comment procède un usager pour réaliser une action, nous devons exprimer la typologie de l'action ainsi que la méthode ou le moyen qu'il utilise. Nous avons par conséquent selon la typologie d'ACTIVITE des MOUVEMENTs possibles différents. Nous avons décrits plus d'une centaine de mouvements de base au total : 58 ACTIVITY CONFIG INFORMATION VULNERABILITY INTENTION AUTHENTICATION Login Logout Backup Restore Locked Add Control Delete Threshold Modify Locked Unlock Backdoor BruteForce Bypass Concealment DoS Gain Hijacking I nformationGathering InformationLeak Injection Overflow Protocol Spoofing Steal Violation Virus Other ATTACK Backdoor BruteForce Bypass DoS Gain I nformationGathering InformationLeak Injection Overflow Protocol Spoofing Steal Violation Other SUSPICIOUS MALWARE BruteForce Virus DoS Other Hijacking Inform ationGathering InformationLeak Injection Overflow Spoofing Violation Other 59 !nu ArTIVITY rcqpir. INFORMATION VI II NERABILITY ATTACK SUSPICIOUS MALWARE RIGHTS Bakup Gain Read Write Delete Restore Add Control BruteForce BruteForce Bypass DirectoryTraversal DoS Gain Violation Other Delete Threshold Modify Bypass Gain InformationGathering InformationLeak Injection Overflow Violation Other DirectoryTraversal DoS Evasion Gain Hijacking InformationGathering InformationLeak Injection Overflow Violation Other 60 INTENTION SYSTEM Stopped Started Restarted Send Receive Execute Ended UP Down Read Gain Write Delete Control Connection Disconnection Forward Backup Restore Add Control Modify Threshold Delete Repair Update Backdoor Bounce Bypass DDoS DirectoryTraversal DoS Evasion Gain InformationGathering InformationLeak Injection Malware Overflow Poisoning spam Spoofing Steel Trojan Violation Virus WORM Other Backdoor Bounce Concealment DDoS DOS Evasion Gain Hijacking InformationGathering InformationLeak Injection Overflow Phishing Physical Poisoning Spoofing Steel Violation Other InnIrsIrs, IC Bounce Concealment DDOS DoS Evasion Gain InformationGathering InformationLeak Injection Overflow Spoofing Violation Virus Worm Other MALWARE PUP Poisoning Spam Spoofing Spyware Steel Trojan Virus Worm Other ACTiViTY CONFiG iNFORivIATiON iULNERABILiTY M I I /\ 3.1 AUTHENTICATION_ACTIVITY Cab:Iodez LOGIN Obiectit AUTHENTICATION_ACTIVITY Contexte: Mots-Clee: IMAMIMMIDIROAR Authentication, login, lagon, user, Account, connected' session, access, authorized Définition CONNEXION d'un utilisateur via le service d'authentification Régies Cible2 est vide dans le cas d'une erreur sur le service d'authentification lors de la connexion d'un utilisateur leteeta Un système d'authentification en cible2 - Un compte ou un attribut d'un compte en ciblel - Cible2 est vide dans le cas d'un succès ou d'un échec de la connexion d'un utilisateur Fe.ex-,Afree.:. Résultats SiegeeZ : Si la connexion via un service d'authentifcation a réussi Faged : Si la connexion via un service d'authentification a échoué, quelque soit la raison invoquée comme un dépassement du nombre de session autorisée ou longueur de password etc... Elle, : S'il y a une erreur sur le fonctionnement du système d'authentification lors d'une connexion Cible s z Mllfflleeellefflla#M1.1001, Ce« 1: un système d'authentification Crevel; a: un compte utilisateur Exemples linux.Rules215 Authentication succeeded Aug 9 02:20:15 localhost login[132]: ROOT LOGIN on Ity1' system.Rules356 Password accepted Feb 15 10:54:21 192.168.11.181 ProxySG: 46000C Accepted password for admin fortigate.rmap 1606 User admin login success fully from GUI Catégorie: LOGOUT Oblece AUTHENTICATION. ACTIVITY Contexte Mots-Clesz Authentication, logout, user, Account, clisconneotecl, session, accesa, unauthorized, endect, terminetedDèfinition DECONNEXION d'un utilisateur via le service d'authentification Règles 1111^MIRII^111^266-II "11MOMMOIVOMMOSIMML Cible2 est vide dans le cas d'une erreur sur le service d'authentification lors de la déconnexion d'un utilisateur Iffdeifeies Un système d'authentification en cible2 - Un compte ou un attribut d'un compte en ciblel - Cible2 est vide dans le cas d'un succès ou d'un échec de la déconnexion d'un utilisateur Faux-Affris Résultats SehGenS : Si la déconnexion d'un utilisateur via le service d'authentification a réussit Page : Si la déconnexion via un service d'authentification a échoué, quelque soit la raison invoquée sur le compte &mi: S'il y a une erreur sur le fonctionnement du système d'authentification lors d'une déconnexion Cibles Cibles I un système d'authentification CibieS 2: un compte utilisateur Exemples ti screencis.Rules511 NetScreen : user logout Jun 16 16:44:38 192.168.15.15 ns208: NetScreen device_id=ns208 system-warning- 00515: Admin user netscreen has logged out via the console (2004-06-16 16:43:56) cisco-fw.rules 1383 Session ended 101 May 10 09:16:36 192.168.11.90 %PIX-5-109012: Authen Session End: user 'exaprobe', sid 0, elapsed 303 seconds courier-mta. ru les 96 IMAP user disconnected 5 Apr 20 09:03:47 host imaplogin: DISCONNECTED, user=toto@test.fr. ip=[::ffft1.1.1.1], headers=5450, body=4684, time=1568 Catégorie: BACKUP obîectitz AUTHENTICATION_ACTIVITY Contexte: Mota-Cleaz Mots-C les: -fflOsIMOASAAUMMOM Authentication, backup, archive, eave, user, account, certificate Définition z- SAUVEGARDE des composants de l'authentification Règles MOMSUISUMMIEIMIlde Cible2 est vide dans le cas d'une erreur sur le service d'authentification lors de la sauvegarde des composants de l'authentification inieedits Un système d'authentification en cible2 Un compte ou un attribut d'un compte en ciblel Cible2 est vide dans le cas de sauvegarde d'un utilisateur ou d'un attribut de l'utilisateur Fatex-Arp Relseetate SieCeee: si la sauvegarde des composants de l'authentification réussit : si la sauvegarde des composants de l'authentification échoue &Me : indique que le service de sauvegarde est en erreur. Cibles; ; Cet« : un système d'authentification Cibles 2: un utilisateur ou un attribut d'un utilisateur Exemples securitywmi.map Certificate services backup completed security._wmi.map 8325 Certificate services backup started security._wmi.map 8855 Certificate services archived a key Catégorie RESTORE Oblectifz AUTHENTICATION. ACTIVITY Contexte: Authentication, restore, importect, user, accotant, certificat» 06f InitIon RESTAURATION des composants de l'authentification comme une Information sur la protection de la cible indiquant la RESTAURATION d'un user, d'un password, d'un certificat Règles Cible2 est vide dans le cas d'une erreur sur le service d'authentification lors de la restauration des composants de l'authentification &leude:. Un système d'authentification en Cible2 Un compte ou un attribut d'un compte en ciblel Cible2 est vide dans le cas de restauration d'un utilisateur ou d'un attribut de l'utilisateur Feux-AveS Rêsultats Succieu.: RESTAURATION réussie des composants de l'authentification Faeid : RESTAURATION échouée des composants de l'authentification EN« : Erreur sur le service de réstauration des composants de l'authentification Cibte ;: CibleS I : un système d'authentification Cibles 2: un utilisateur, un attribut de l'utilisateur ou vide Exemptes system_wmi.map 940 Restoring missing user account database security_wmi.map 8421 Certificate services restore completed 3.2 AUTHENTICATION CONFIG Catégorie; ADD Obiectit AUTHENTICATIONCONFIG Contexte: SIAJIMMIRINIMMOI MNDMIAllIDAM1111133102-8^116-8.. Mots-Cies: '111011-MMellIDDIDIMe Authenticat&on, add, create, certilicate, user, account, paeaword, credential Définition AJOUT d'un utilisateur, d'un certificat, d'un mot de passe, d'un credential ou d'un service d'authentification. Regtee M.1.1M11111^11--------11^ Cible2 est vide dans le cas d'une erreur sur le service d'authentification lors de l'ajout d'un utilisateur, d'un certificat, d'un mot de passe, d'un credential ou d'un service d'authentification. ',Me/rets: Un système d'authentification en cible2 Un compte ou un attribut d'un compte en ciblel Cible2 est vide si l'objet ajouté est différent du service d'authentification Faux-Amie : Resuitate .1^1111.11,01elelelinaRW StiCeeee si l'ajout a réusi Fade : si l'ajout a échoué &Mir : s'il y a une erreur sur le service de configuration lors de l'ajout Cibles Cibies t système d'authentification Cibles 2: un utilisateur, un password, un certificat, un credential ou vide Exemples shadow-utils.Rules49 User Created May 10 16:37:57 somehost useradd[621]: new user: name=clamav, uid=46, gid=46, home=/tmp, shell=/sbin/nologin cisco-pix.Rules1206 User added May 10 08:40:42 192.168.11.90 %PIX-5-502101: New user added to local dbase: Uname: exaprobe Priv: 15 Encpass: xxxxxxxxx screenos.Ru1es672 NetScreen : Web management user account added Feb 7 10:48:34 192.168.10.185 Catégorie: DELETE Oblectif: AUTHENTICATION_CONFIG Contexte.: Authenticatiori' delta», rernove, revake' certifIcate, user, account, pasaword, credentlalDelnitlon SUPPRESSION d'un utilisateur, d'un password, d'un credential, d'un certificate ou du service d'authentification Règles 701011111113111.MOSMIle Cible2 est vide dans le cas d'une erreur sur le service d'authentification lors de la suppression d'un utilisateur, d'un certificat, d'un mot de passe, d'un credential ou d'un service d'authentification. Wei/di/4 Un système d'authentification en cible2 Un compte ou un attribut d'un compte en ciblel Cible2 est vide si l'objet supprimé est différent du service d'authentification Fa Aania Rdsulitats Siee,.,eSe.": si la suppression a réussi Fagad : si la suppression a échoué &Jiu: s'il y a une erreur sur le service de configuration lors de la suppression Cibles Cita« Système d'authentification Cites 2'; un tilisateur, un password, un certificat, un credential ou vide Exemples esmp_admin.Rules36 ESMP : account deleted 2004-03-05 09:33:21 [http10443-Processor6] 'cpommier'@'192.168.1.13' delete an exaprotect account lucentrules 1774 Delete Authentication Service shadow-utils.rules 277 User deleted :2 Cab:mode: MOOIFY AUTHENTICATION__CONFIG Oblecti Contexte: SealleeMIMMAMI MIMORIMEIROSIMIM. Mots-Clesz Authentication, Modify' change, replace, certificats, user, accoure, pasaword, credential' update Définition MODIFICATION de la configuration d'un utilisateur, d'un password, d'un credential, d'un certificat ou d'un service d'authentification. Règles Cible2 est vide dans le cas d'une erreur sur le service d'authentification lors de la modification d'un utilisateur, d'un certificat, d'un mot de passe, d'un credential ou d'un service d'authentification. Weide Un système d'authentification en cible2 Un compte ou un attribut d'un compte en ciblel Cible2 est vide si l'objet modifié est différent du service d'authentification SysAuth en cible2 Fatex-Ahmie.:' RelStkiltatti Sielegee: si la modification a réusi Faed : si la modification a échoué &mi: s'il y a une erreur sur le service de l'authentification lors de la modification Cibles Citties t : un système d'authentification Citrie$ 2: un utilisateur, un certificat, un password, un credential ou vide Exemples security_wmi.map 2464 Trusted domain modified Access_Config.NetBios. Modified(1) bluecoat system.Rules306 Password changed Feb 01 15:28:37 192.168.11.181 ProxySG: 160002 SSH admin at 192.168.10.12, AccessConfig.PKI.Conf file_Modified security_wmi.map 8738 Configuration entry changed in certificate services Catégorie: LOCKED Oblectit AUTHENTICATION_CONFIG Contexte: Authepntication, session, tocked, disabled, user, account Définition z. -seesefflawasneaumea eatesau. Vérouillage d'un utilisateur de domaine ou d'un utilisateur local suivant la configuration de la statégie de vérouillage par le système d'authentification. Règles Un système d'authentification en cible2 Un compte ou un attribut d'un compte en ciblel Cible2 est vide dans le cas de succès et d'échec Faux-AD-ris : Résultats Vérouillage réussi Feed : vérrouillage échoué : erreur sur le service d'authentification pour le vérouillage d'un utilisateur Cibles, Cibles un système d'authentification Cibles 2: un utilisateur ou vide dans le cas d'erreur. Exemptes esmp_admin.rules 191 ESMP : account Iocked system_wmi.map 1732 User account Iocked out Catégorie: UNLOCK Oblectif: AUTHENTICATION_CONFIG Contexte: Mots-Ciea: Authentioation, session, untocked' enabted, user, account Définition «Mele0MAIIAMMR0 Dévérouillage par le système d'authentification d'un utilisateur de domaine ou d'un utilisateur local Régies intexas - Un système d'authentification en cible2 - Un compte ou un attribut d'un compte en ciblel - Cible2 est vide dans le cas de succès et d'échec Faux-Anie Résultats Stemee: Dévérouillage réussi FaMed : Dévérouillage échoué eget : erreur sur le service d'authnetification lors du dévérouillage d'un utilisateur. Cibles Cibiet 1: un service d'authentification Cibiete : un utilisateur ou vide dans le cas d'erreur Exemples esmp_admin.rules 239 ESMP : account unlocked security_wmi.map 7237 User account unlocked AUTHENTICATION INFORMATION Catégorie: CONTROL Obiectif: AUTHENTICATION INFORMATION Contexte: Mots-Clesz Authentication, session, valid, exist, normal, invaild, require, check, certificat», user, account, password, credentiai Définition Informations indiquant l'état de la connexion, l'authentifieur, l'authentifié ou un attribut de l'authentifié comme password, certificat, etc. Règle% Intente : - Un système d'authentification en cible2 - Un compte ou un attribut d'un compte en ciblel Faux-Amie .:: Résultats Vaiid Résultat d'un CONTROLE indiquant l'état VALIDE de la connexion ou de l'authentifieur ou de l'authentifié ou un attribut de l'authentifié comme password, certificat. Iewaiid Résultat d'un CONTROLE indiquant l'état INVALIDE de la connexion ou de l'authentifieur ou de l'authentifié ou un attribut de l'authentifié comme password, certificat. Mte Informations NOTIFIANT un utilisateur ou un atribut d'un utilisateur Cibles Cibles I k un système d'authentification Cibles 2 un utilisateur, Credential, Passworcl Certificate, ConfFile, Format, Method, Name, Parameter, Version, Address Exemptes security_wmi.map 11170 Specified account name not a member of the local group security_wmi.map 5004 User already exists Access_Activity.lpsec. Terminated security_wmi.map 1380 IP Security Key Exchange ended Cattiorie: THRESHOLD Obiettif: Contexte:. AUTHENTICATION_INFORMATION Mots-Cies: Authentication' iimit, maximum, maximum, too many, expired, exceeded, reached, user, account, session, certificate, credential Définition selllEMIMMAMMRIX. Informations indiquant les seuils d'utilisation d'un service d'authentification, de la connexion, de l'authentifié ou d'un attribut de l'authentifié comme password, certificat, ou credential Règles ifttffliiee Un système d'authentification en cible2 Un compte ou un attribut d'un compte en ciblel Faux-Amis :: Rêsulltate IffllellIDAIMMEM111# ExpisedEt Résultat Informations indiquant l'expiration du compte, de mot de passe, de credential, de certificat:, de la session EXceeded Informations indiquant une utilisation DEPASSEE ou HAUTE d'un service d'authentification, de la connexion, de l'authentifié ou d'un attribut de l'authentifié comme password, certificat, ou credential AbtWei Informations indiquant une utilisation normal des seuils prévus pour les composants du service d'authentification Cibles : Cibles 1 un système d'authentification Ci lest 4 Account, password, certificate, credential, ConfFile, Format, Method, Name, Parameter, Version, AddressExemptes Access _Activity.Auth. Expired radius.Rules35 Radius: password expired log(L. AUTH, "unix_pass: [%s]: password has expired", name) radiusRules49 Radius: account expired Iog(L_AUTH, "unix_pass: [%s]: account has expired" security_wmi.map 11254 Maximum number of secrets exceeded system_ wmi.map 1928 Exceeded account limitation AUTHENTICATION_ATTACK Catégorie: BRUTE FORCE Oblectit AUTHENTICATION_ATTACK Contexte: Mots-Clesz Brute Force, user password, Réfiniition egellAIIMOMMARR(Oleff010AM, ATTAQUE sur le service d'AUTHENTIFICATION de type Brute Force Règles 1ezieedie$::: Un système d'authentification en cible2 Un compte ou un attribut d'un compte en ciblel Faux-Amie Résultats Detected : Détection de l'attaque Cibles Cittietl: un système d'authentification Cibles 2 un utilisateur ou un attribute d'un utilisateur Exemptes mcafee_intrushield.map 4496 RADIUS: Authentication Brute Force 0x40012c00 Catdeorie: BYPASS Oblectit AUTHENTICATION_ATTACK Contexte: Mots-Clesz Bypass, ,Authentication Bypass Deflnition ATTAQIJE sur le service d'AUTHENTIFICATION de type Bypass Règles z: leterdi,ts - SyeAtith en *Me 2 Fatee-Anes Rdsuitata Detected : Détection de l'attaque Cibles Cibles Ir :SysAuth *Mes 2 Exemples z. mcafeeintrushield HTTP: PHPBB Admin Authentication Bypass 0x40220200 Catdgorke DOS Objectif: ..»AUTHENTICATION_ATTACK Contexte: Mots-Clea: Dosa, IDEmiall of Service, crash Définition ATTAQUE sur le service d'AUTHENTIFICATION de type DOS Règles inteejte Syet&e, en eie 2 Résultats Faux-Amis Detected : Détection de l'attaque Cibles Cibles SystAuth Cibles Exemples mcafee_.intrushield SSH: Cisco Catalyst SSH Mismatch Crash Ox45b00d00 Catégorie: GAIN Oblectif: AUTHENTICATION_ATTACK Contexte:: .101111WIMMAIIMIRIMIIM Mots-Clesz Exploit Définition ATTAQUE sur le service d'AUTHENTIFICATION de type Gain (Exploit) Règle:a tete le Faux,Amis: Résultats Detected : Détection de l'attaque Cibies Cites 2: Exemples MVIMIIMPSOMMOMMOTOOO. mcafee_intrushield DHCP: Root Exploit in DHCP Client 0x42600100 Cati:leude HIJACKING Objectif: AUTHENTICATION_ATTACK. Contexte:. Mota-C tes Flqactiang, Définition ATTAQUE sur le service d'AUTHENTIFICATION de type Hijacking Règtes lagefaz Faux-Amie .:-: Reteultats efflefflEMMEMllgel1MIMY Detected : Détection de l'attaque Cibles Caltes I Cibles 2: Exemptes Catégorie; INFORMATIONGATHERING Oblectif: AUTHENTICATION_ATTACK Contexte:. Mota-Cteaz InformationGathering, Version, port recognition Définition «0«....«--^^^-^-^-^«IMPPOIIIIIII. ATTAQIJE sur le service d'AUTHENTIFICATION de type INFORMATIONGATHERING Règles ieteffedits Fattx-Ainai.% Réetihtats Detected : Détection de l'attaque Cibles, Cibles I Cibles Exemples mcafee_intrushield NETBIOS-SS: User Enumeration 0x40704f00 Catégorie; INFORMATIONLEAK obiectit Contexte: 911MM^«.111110101 Leak Déflnittion ATTAQUE sur le service d'AUTHENTIFICATION de type INFORMATIONLEAK Règles ;. bige dits, Faux-Airis RdeuIrtate -{IMMIDDAM011111111MI Detected : Détection de l'attaque Ciblera Cibles I Cibles â z ExeinnIplea mcafeeintrushield HTTP: Finger Leak User Info 0x40204e00 AUTHENTICATION_ATTACK Catégovice INJECTION Oblectit AUTHENTICATION ATTACK Contexte: dots-Ctesz Injection, command execution, code execution, cgi, script Définition z ATTAQUE sur le service d'AUTHENTIFICATION de type INJECTION Règles Inteirdee Faux-6teni$ Résultats z yffl121118-ZIMIIMEMefflaly1M. Detected : Détection de l'attaque Cibles z Cibles Cibles 2 Exemples z mcafee_intrushield FTP: Pwd Format String 0x40502100 Catégorie: OVERFLOW Oblectit AUTHENTICATION ATTACK Contexte: Mots-Clesz Overflow, Buffer Overflow, Définition .1.10MISMIIMMODIA ATTAQUE sur le service d'AUTHENTIFICATION de type OVERFLOW Règles Feta-M/s Rdaulltats Detected : Détection de l'attaque Cibles, Cibles Cgaires 2' Exemples mcafee_intrushield TELNET: System V Derived Login Buffer Overflow 0x40602300 Catégorie: VIOLATION Obiectit AUTHENTICATION ATTACK Contexte:. Mots-Cies: Violation, Définition z ATTAQUE sur le service d'AUTHENTIFICATION de type VIOLATION Règles ifb2,4t-ie Fat«-ierià Résultats : Detected : Détection de l'attaque Cibles :. 1150111M6M1IMMIMIME011. Cibles Cibles 2 Exemples Catégorie: OTHER oblecritz AUTHENTICATION_ATTACK Contextez. finition ATTAQUE sur le service d'AUTHENTIFICATION de type différent des types d'attaque cités cidessuslRègleits leude Faux-Amie Resultata Detected : Détection de l'attaque Cibles 'efeellefIffSIDIMMIMIMM. Cibles 'Pz Cibles Exemples Ifttlafflat^IIMIIter{{1211{11, mcafee_intrushield.map 5864 TELNET: Root Login with Wrong Password 0x40601000 AUTHENTICATION_MALWARE Catdeoute: VIRUS Oblectif: AUTHENTICATIONMALWARE Contexte: Motet-Clesz Virus, infected Définition MALWARE détecté sur le service d'authentification de type VIRUS Règles Irlefees Faux-Amie Résultats detected Cibles Cibles 1: Cibles 2: Exemples Catégorie: OTHER Obiectif: AUTHENTICATION_MALWARE Contexte: Mots-Cies: Définition z MALWARE détecté sur le service d'authentification de type autre que VIRUS Règles z inteit dits .:- Fata-Avge Résultats detectecl Cibles' Cibles l' Cibles 2: Exemptes z application_wmi File infected 3.3 AUTHENTICATION SUSPICIOUS Catdeorte BRUTE FORCE Oblectit AUTHENTICATON_SUSPICIOUS Contexte: Mots-Clea: Attempt, attepiolous, BRUTE FORCE, Définition 411.M*11. ACTIVITE SUSPECTE sur le service d'AUTHENTIFICATION de type BRUTEFORCE Détectée Règlelà intenigs Faux-ents : Résultats detectecl Cibles Cibles t Cibles 2 Exemptes Catégorie; DOS Obiectit AUTHENTICATIOR_SUSPICIOUS Contexte: Mota-'Cteaz Ancrage, atispiceaus, DOS, Denlal cf service Définition 7111W111111111111111.60111.01111 ACTIVITE SUSPECTE sur le service d'AUTHENTIFICATION de type DOS Détectée Règlea inteelies Faex-eunie Relecunata detected Cibles Cibles 2: Exemptes Catheorte: HIJACKING Oblectit AUTHENTICATONSUSPICIOUS Contexte: Mota-Cleaz Atteinte, suapiclous, Hijacking Définition ACTIVITE SUSPECTE sur le service d'AUTHENTIFICATION de type Hijacking détectée Règles 'Merdes Faex-Ares:-: Résuirtate detected Cibleee Cite« ables 2 Exemptes Catégorie: °blettit INFORMATIONGATHERING Contexte: AUTHENTICATION_SUSPICIOUS Ntota-Cteaz: Attempt, suspicions, recognition Définition ACTIVITE SUSPECTE sur le service d'AUTHENTIFICATION de type INFORMATIONGATHERING (collecte d'information) collectée. Règle:a ete Faux-Amie .:: Résultats detectecl C able Ml z. Cibles 1 Ciees 2: Exemptes z Catégorie: INFORMATIONLEAK Objectif: Contexte: AUTHENTICATION_SUSPICIOUS Attempt, suspicioute, Lealt Définition ACTIVITE SUSPECTE sur le service d'AUTHENTIFICATION de type INFORMATIONLEAK (fuite d'information) détectée Règles irgerziee Faux-Amie Résultats detectecl Cibles. : Cibles 1 Cibles 2: Exemples z 0 Catégorie: INJECTION Oblectlf: AUTHENTICATON__SUSPICIOUS Contexte:. Mots.Clesz Attempt, susplclous' INJECTION Delniition ACTIVITE SUSPECTE sur le service d'AUTHENTIFICATION de type INJECTION détectée Règles rotor,ce Fatex-Avee Rdsullets detected Cibles Cittiest: Exemples 1 Catégorie: OVERF LOW Obiectit AUTHENTICATION_SUSPICIOUS Contexte: Mots-Clee: Attempt, auspacioue, OVERFLOW Définition ACTIVITE SUSPECTE sur le service d'AUTHENTIFICATION de type OVERFLOW détectée Règles AMA^1^11MODDAMIll inteees Faux-eke Résultats detectecl Cibles; z CUUes Cibles 2!: Exemples z 2 Catégorie: VIOLATION Oblectit Contexte: Mots-Cies: AUTHENTICATON_SUSPICIOUS Attempt, stispiolous, VIOLATION Définition ACTIVITE SUSPECTE sur le service d'AUTHENTIFICATION de type VIOLATION détectée Règles Intenigs Faux-An Résuktats detectecl Cibles Cibles l' Cibles 2: Exemples 3 Catégorie: OTHER Oblectit AUTHENTICATON_SUSPICIOUS Contexte: Mots-Glas: Attempt, auspic loue, Définition ACTIVITE SUSPECTE sur le service d'AUTHENTIFICATION de type différents des types d'activités suspectes citées ci-dessus Règles leneedite t=aux-Arnia Résultats detectecl Cibles, 1333381MADDIUMMILIMMIIA, Cetes I Chies 2 Exemples niksun_netdetector_db.map 144 An attempted login using a suspicious username was Datected snort.Rules686 $3 Classification An attempted login using a suspicious username was 12e(eaed ICMP snort. Ru les704 $3 Classification An attempted log in using a sus 4 AUTHENTICATION_VULNERABILITY Catelernie: BACKDOOR Oblectit AUTHENTICATION_VULNERABILITY Contexte: Mota'ara Vulnerability, Backdoor, detection Définition z VULNERABILITE sur le service d'AUTHENTIFICATION de type BACKDOOR détectée Regtee 11611^11116611611111MMIIIIMMIL Inte/dite: Faux-Amie:: Résultats detectecl Cibles, Cibles 1: Cibles 2 : Exemptes Catégorie: BRUTE FORCE Oblectit Contexte: AUTHENTICATION_VULNERABILITY Mota-Cles: Vulnerability' BRUTEFORCE, too weak, ciear text, default password, Cieartext Login Définition z VULNERABILITE sur le service d'AUTHENTIFICATION de type BRUTEFORCE détectée Règles ^IMMID1160105MMAIIIIIMMe. Fate-Acnie Résultats detecteci Cibles 1. Cibles t Cibles 2!: Exemptes 6 Cab:morte: BYPASS obiectit AUTHENTICATION_VULNERABILITY Contexte:: Mots-Cies:: Vulnerability' Bypaaa, Définition z ^31.331138^1ffleedel«1114 VULNERABILITE sur le service d'AUTHENTIFICATION de type BYPASS détectée Règles rz 41111161M1MIDDMÉMIME. leteldee .:- Fatex-Arnie Résultats ; detectecl Cibles Cibles Cib' tes 2: Exemples 7 Catégorie: CONCEALMENT Oblettlt AUTHENTICATION_VULNERABILITY Contexte;. Mots-Cles: VulnerabIllty, CONCEALMENT DéfInhtion VULNERABILITE sur le service d'AUTHENTIFICATION de type CONCEALMENT Règles Faux-Amie .:: Relsultats detected Cibles Cibles Cibles 2 Exemples 8 Catégorie: DOS Oblectit AUTHENTICATION_VULNERABILITY Contexte Mots-Ciesz Vulnerability, DOS, crash, Dental of Service Vulnerabllity Définition VULNERABILITE sur le service d'AUTHENTIFICATION de type DOS détectée Règles /Menties Faux-Amis Résultats detecteci Cibles CffikeS t Cibles 2: Exemples 9 Catégorie: GAIN Oblectif: AUTHENTICATION_VULNERABILITY Contexte: Mots-Cles Vulnerability, GAIN Définition z' VULNERABILITE sur le service d'AUTHENTIFICATION de type GAIN détectée Règles »me Fatvx-Arni.s Résultats z detectecl Cibles z Cibles Cibles Exemptes z 0 Catégorie: HIJACKING Oblectif: Contexte: AUTHENTICATION.yuLNERABILITY Mots-Cleaz Vulnerability, FILIACKING Définition z VULNERABILITE sur le service d'AUTHENTIFICATION de type HIJACKING détectée Réetes leterldits Fate.Avile Résultats detectecl Cibles Cibles t Cibles 2: Exemples 1 Catégorie: 1NFORMATIONGATHERING oblectit AUTHENTICATION_VULNERABILITY Contexte Mote-Cleaz Vulnerability, Probe Définition z VULNEIRABILITE sur le service d'AUTHENTIFICATION de type INFORMATIONGATHERING détectéeRintee ffitetees Faux-Amie .:: Rdeuktate .21MMUReemetelaeteameam detected Cibiege Cibles Cibles 2 Exemptes 'z 2 Catégorie: INFORMATIONLEAK Obiectit Contexte: AUTHENTICATION_VULNERABILITY Mots-Cies:. Vulnerability, Leak Définition 7.. VULNERABILITE sur le service d'AUTHENTIFICATION de type INFORMATIONLEAK détectée Régies 1,nteette Résultats AeSSIMSleMMARIIMMMARRIA. detected Cibles Cibles 1- Cibles 2 Exemples 3 CatElootte: INJECTION Obiectit AUTHENTICATION_VULNERABILITY Contexte:. Mots-Cies: Vulnerability, INJECTION' format string vulnerability Définition 41.1.15111111MAMMIMMe»11. VULNERABILITE sur le service d'AUTHENTIFICATION de type INJECTION détectéeRieoltest Feex.A+We Résultats detecteci Cibles Cibles t C uves 2: Exemptes z 4 Catégorie: OTHER Oblectit AUTHENTICATION_VULNERABILITY Contexte: Mote-Cleez Vulnerability, Définition VULNERABILITE sur le service d'AUTHENTIFICATION détectée de type différents des autres vulnérabilités citéesRègiee 111MOMOMMEMAIIM1111.1. Intetas Fata-Arnie Rdauttate detecteci Cible* z Wales t Cibles 2: Exemplea Catégorie: OVERFLOW Obiectitz Contexte:: AUTHENTICATION_VULNERABILITY Mots-'f les: Vulnerability' overflow exploitation Définition VULNERABILITE sur le service d'AUTHENTIFICATION de type OVERFLOW détectée Règles intent4 Faux-Aillez Rdsuitats SUMMIDEMMAIMMEIM detected Clbles MR09:«MADDIII0IMINIDO. cite« cita« Exemples 6 Catégorie: PROTOCOL AUTHENTICATION_VULNERABILITY Contexte:: Mota-Clea: Vulnerabillty, Définition MIMMIMAIMIRIMMMee VULNERABILITE sur le service d'AUTHENTIFICATION de type PROTOCOL détectée Règles z Inteadie Faux-Amie ::: Résultats detected Cibles Cibles 1: Cibles 2 Exemples 7 Catégorle: SPOOFING °blettit. Contexte AUTHENTICATION_VULNERABILITY Mots-Cies:: Vulnerability, SPOOFING, as user VULNERABILITE sur le service d'AUTHENTIFICATION de type SPOOFING détectée Règles 7---^--^-MMMMMI interdits : Fake-4uris : Résultats IMISAAMIMADAMADMAIll detected Cibles 170MISSAMMODDDIIMMIMIL Cibles it Cibles 2: Exemples .1 8 Catégorie: STEAL Oblectit AUTHENTICATIONyuLNERABILITY Contexte Motu-Cies: Vulnerability, STEAL Définition z VULNERABILITE sur le service d'AUTHENTIFICATION de type STEAL détectée Règle:a Interdits Faux-Anas Résultats z. detectecl Cibles Cibles lr Cibles 2 Exemples 9 Catégorie: VIOLATION Oblectit AUTHENTICATION_VULNERABILITY Contexte;« Mots-Cletaz Vulnerabllity, VIOLATION Eléfinition z VULNERABILITE sur le service d'AUTHENTIFICATION de type VIOLATION détectée Règle:a z inteadits Faux-Aes Relu nets detected Cibles Cibles t Cibles 2 Exemptes 0 Catégorie: VIRUS Oblectit AUTHENTICATION_VULNERABILITY Contexte:: Nota-Ciel; Vulnerability, VIRUS Définition VULNERABILITE sur le service d'AUTHENTIFICATION de type VIRUS détectée Règles Faux-Amis Résuttats 111111^1^111.111fflefflefflelleill Detected IMAOMMIMMellfflII1115D2076 Cibles Cibles 2 Exemptes 1 3.4 RIGHTS_ACTIVITY Catégorie: GAIN Oblectit RIGHTS_ACTIVITY Contextez MotewClesz 411^1100.1-^-^--11. Access, command, PrivIlege, assigned, galned, sudo, rIghts, user Définition 4111.1111.11-11M1M111111. GAIN de PRIVILEGE d'un admin ou d'un user sur toutes les ressources qu'elles soient utilisateur ou système Règles »m'Ides - Un utilisateur en cible1 - Command, un service ou un host en cible2 - File, data, directory , message en ciblel ou cible2 Faux-Amis Résultats rz 11.2.11161.1!MM1111, 11.011M6MVAMAAAAMAM. StZene Gain de privilège réussi Faited : Gain de privilège echoué En or : Erreur dans le service qui gère les droits Cages Cibles 1 un service, un host ou une commande Cibles 2> un utilisateur Exemples security_wmi.map 1906 Special privileges assigned to new logon 2 sudo.ru les 37 SUDO from Unauthorized User. Jan 15 09:53:11 12.34.56.78 sudo: ekwong : user NOT in sudoers , TTY=pts/2 , PWD=/ , USER=root , COMM AN D=/bin/ls mcafee_intrushield.map2218 TELN ET: Cisco 675 Root Privilege Gained 0x40602200 2 3 Catégorie: READ Oblectlf: RIGHTS_ACTIVITY Contexte: MM. 411/1M1111^01MMIVIIMMIL Mots-iClesz Read' File, Directory, data' Access, permission, user Définition GAIN EN LECTURE sur une ressource privilégiée par un user, un admin, un invité, un groupe de user, Règles ieteedds - Un utilisateur, file, directory, data, message ou command en ciblel - Command, un service ou un host en cible2 Fatex-Affnie Résultats z kie,CeSS Lecture réussie de la ressource Palle : Lecture échouée de la ressource Eu« : Erreur sur le service qui gère les doits pour la lecture de la ressource Cibles Cibles un service ou un host Cibles : File, data, directory, message Exemples sgs.rules 729 Access denied by remote client 36 Duration=2.465049, ID=47PY, Sent=3152, Received=23266, Bytes=26418, Server Source=57.227.211.5, Server Source Port=49358, State=rsairc4_128_md5 4 Catégorie: WRITE Obieretif: RIGHTS_ACTIVITY Contexte:. .154/0-^^----IMMINa FRAMMIMIOMMIgeirtel Ira I. Mots-Ctea Write., File, Directory, data, Access* permission, user (»finition ; GAIN EN ECRITURE sur une ressource privilégiée par un user, un admin, un invité, un groupe de user, Règles 1.«19Men1 1 ellfflffeffle e 40.11, inteet$ Un utilisateur, file, directory, data ou command en ciblel Command, un service ou un host en cible2 Fatex-Amis Rèsuttats -R^68.1.6-1^11.11AMMO 9Alleffl1M10111111MAAMIAAM4 &mese Ecriture réussi sur la ressource Fade : Ecriture échouée sur la ressource Egmf : Erreur sur le service qui gère les doits pour l'ecriture sur la ressource Cibles; Cibles : un service ou un host Cibiet 2: File, data, directory, message Exemples ; epo_db 211 Media is write protected. 6 Catégorie: DELETE Oblectif: RIGHTS_ACTIVITY Contexte: Mots-IC:1es: Delete, remove, file, directory, data, permission, user Définition 7111.3,11^1110 .1111-11110 SUPPRESSION réussie d'une ressource privilégiée par un user, un admin, un invité, un groupe de user, Régies - Un utilisateur, file, directory, data ou command en ciblel - Command, un service ou un host en cible2 Faux-Amis:: Résultats MEM Suppression réussie de la ressource Faite : Suppression échouée de la ressource Enrer : Erreur sur le service qui gère les doits de la suppression de la ressource Cibles, el* 011.1111.111, Citietal un service ou un host Cibles 2' File, data, directory, message Exemples shadow-utils.Rules291 Group deleted Nov 4 15:18:16 exatestl userdel[10259]: remove group 'testuser' 7 Access_Config.Group. Deleted shadow- utils.Rules291 Group deleted Nov 4 15:18:16 exatestl userdel[10259]: remove group 'testuser' 8 Catégorie: BACKUP Oblectit RIGHTS_ACTIVITY Contexte:. D/iota-Cies: Backup, dotes, aave, user' permission, accesa' file, data, directory Définition SAUVEGARDE des droits d'un utilissateur, d'un admin, d'un invité, d'un groupe user ou des droits d'accès sur une donnée, un fichier ou une directory Règles irleeleS - Un utilisateur, file, directory, data, message ou command en ciblel - Command, un service ou un host en cible2 Faux-Ante Résultats UGGEtel : SAUVEGARDE réussie des droits Feel : Echec de SAUVEGARDE des droits Eiger : Erreur dans la SAUVEGARDE des droits Cliates Cible* un service ou un host Mite 2: File, data, directory, message Exemptes 9 security_wmi.map 6303 Backup of data protection master key 0 Catégorie: RESTORE °blettit: RIGHTS_ACTIVITY Contexte:. Mots-Cies: Restore, rights' imported' user, permission, access, file, data, directory Définition RESTAIJRATION de droits d'un utilisateur, d'un admin, d'un invité, d'un groupe user ou des droits d'accès sur une donnée, un fichier ou une directory Règles /Mentie Un utilisateur, file, directory, data, message ou command en ciblel Command, group, un service ou un host en cible2 Résultats ee Restauration réussie des droits Faged : Echec de restauration des droits Eimr: Erreur dans la restauration des des droits Cibles *1910177176^1. Cibles 11: un service ou un host Cibles 2. File, data, directory, user Exemptes 31 security_wmi.map 8304 Certificate services backup completed security_wmi.map 6331 Recovery of data protection master key 2 RIGHTS_CONFIG RIGHTS_CONFIG Cat69orke ADD Objectif: Contexte: Mots-Clesz Add, created, group, user, rights, file, data, directory Définition 11M11811^MIllffle111M16. AJOUT de DROITS sur une ressource d'un utilisateur, d'un admin, d'un groupe utilisateurser. La ressource peut être un fichier, un répertoire, des données. Ou Ajout d'un utilisateur, d'un admin à un groupe utilisateurser Règles intenlzka Un utilisateur, file, directory, data, message ou command en ciblel Command, group, un service ou un host en cible2 Faux-AirWs.:. Résultats Steefeee : AJOUT de DROITS réussi Fade : Echec dans l'ajout de DROITS Eu« : Erreur sur l'ajout de DROITS Cibles. Cibles I un service ou un host Cibles 2 File, data, directory, message, un utilisateur Exemples 3 security_wmi.map 4278 Universal group created security_wmi.map 3244 Member added to a local group shadow-utils.Rules33 Group Created with GID 0 May 10 16:37:57 somehost groupadd[618]: new group: name=wheel, gid=0 4 Catégorie; DELETE Obiectit RIGHTS_CONFIG Contexte:. D/iota-Cies: Delete, rernove, group, user' rights, file, data, directory Définition 98111«el1011-11001116.11,111 SUPPRESSION de DROITS sur une ressource d'un utilisateur, d'un admin, d'un groupe utilisateurser. La ressource peut être un fichier, un répertoire, des données. Ou SUPPRESSION d'un utilisateur, d'un admin d'un groupe utilisateurser Règles /nteedee Un utilisateur, file, directory, data, message ou command en ciblel Command, group, un service ou un host en cible2 Faux- Amie .:- Résultats .1.1515111MDEMISIIDSMInll. SteCEMS :- Suppression de DROITS réussi Paeed : Echec dans la suppression de DROITS Eau: Erreur sur la suppression de DROITS Cibles, Cibles Cibles : un service ou un host Cibles 2: File, data, directory, message, un utilisateur Exemples nsm.Rules140 Config service deleted Dec 5 16:24:46 192.168.10.202 20051205, 7328, 2005/12/05 15:24:45, 2005/12/05 14:19:51, global, 0, ns5xp, config, service, (NULL), (NULL), 0.0.0.0, 0, 0.0.0.0, 0, (NULL), (NULL), 0.0.0.0, 0, 0.0.0.0, 0, 255, SYSTEM shadow-utils.rules 292 Group deleted security_wmi.map 2192 User right removed 6 Catégorie: MODIFY Oblectit RIGHTS_CONFIG Contexte: Mots-Cleaz Modify, change, replace, moue, group' user, rIghts, file, data, directory D6fInition MODIFICATION de DROITS sur une ressource d'un utilisateur, d'un admin, d'un groupe utilisateurser. La ressource peut être un fichier, un répertoire, des données. Ou MODIFICATION de configuration de droits d'un groupe utilisateurser Règle:a -elllERMIAMMEIM.^ IIIMM^17011AMMIL inteidita Un utilisateur, file, directory, data, message ou command en ciblel Command, group, un service ou un host en cible2 Faux-Amis Rèsultats MIID11.1611111Alell6RIMAIMI. SkiCoeSe:: Modification de DROITS réussie Faite : Echec dans la modification de DROITS &Mt': Erreur sur la modification de DROITS Cibles Cibles 1' un service ou un host Ce« 2: File, data, directory, message, un utilisateur Exemples security_wmi.map 2160 User right assigned 7 security_wmi.map 4344 Universal group changed security_wmi.map 2220 User right removed 15 RIGHTS_INFORMATION Catégorie: CONTROL Oblectilz RIGHTS_INFORMATION Contexte: D/Iota-Cies: .6192CDRIEIllAIMMIMV valid, invalid, notify, exist, check, normal, group, file, data, Définition Informations indiquant I' etat de control des droits d'une ressource Reniiez IMODAMMID11^161AMMelle. Inteidiks Un utilisateur, file, directory, data, message ou command en ciblel Command, group, un service ou un host en cible2 Faux-Amis Résultats MIRSIMMMIDAMIL. Va id Informations indiquant l'état de contrôl valid des droits d'une ressource inved Informations indiquant l'état de contrôl invalid des droits d'une ressource Ne*: Informations indiquant une notification suite à un contrôl des droits d'une ressource Ciblee Cibles / 4 un service ou un host 8 Cibles 2 File, data, directory, message, un utilisateur Exemples ,z security_wmi.map 9450 Group may not be disabled security_wmi.map 3894 Created local group disabled system_wmi.map 4022 User not belonged to a group 9 Catégorie: THRESHOLD Oblectit RIGHTS_INFORMATION Contexte:. AMIMMOIP111-11.111M-11^11-6 Mots-Cleaz Limit' maximum number, maximum tength, tao many, expired, exceededDéfinition Informations indiquant une utilisation DEPASSEE des droits sur une ressource Règle:a Un utilisateur, file, directory, data, message ou command en ciblel Command, group, un service ou un host en cible2 Faux-Amie Rèaultats Expinet Informations indiquant l'expiration des droits EXceected Informations indiquant une utilisation DEIPASSEE ou HAUTE des droits Me fele Informations indiquant une utilisation normal des droits prévus C b tes Cibles 1 un service ou un host Cibles 2!: File, data, directory, message, un utilisateur Exemples security_wmi.map 11496 Too many security IDs specified 0 RIGHTS_ATTACK Catégorie: BYPASS ablectit RIGHTS_ATTACK Contexte: ellote-Cteaz Définition Règles interdits Faux-Ainis Résultats detected Ciblen Cibles Cibles 2 Exemptes 1 Catégorie: DIRECTORYTRAVERSAL Oblectit: RIGHTS_ATTACK Contexte: Mots-Cles: Définition z Régies intepet$ Fata-Avnie Résultats detected Cibles Cibles l: Cibles 2 Exemples 2 Catégorie: GAIN Oblectit: RIGHTS_ATTACK Contexte: Mots-Cies: Définition Règles inteeeta Fata-Autà Releuitate detectecl Cibles; S^^-AllIZIIMIIMMS1011. Cees 1' *bene 2 Exemples 3 Catégorie: Obiectit RIGHTS_ATTACK INFORMATIONGATHERING Contexte: Motu-Cies:. Définition Règles z leuelita Faux-Ainia Résultats detectecl Cibles z. .10111.211101MMISIMMI^8. Cible* 1 Cules 2 Exemptes 4 Catégorie: INJECTION Obientit RIGHTS_ATTACK Contsxte:. Mots.Cleaz Définition Règles :z -11^11DMA0.001011:10MIDDll. in4eaelite Faux-Anie .:-: Résultats z. detected Cibles 11.6105VM1.1.01«1«03, Cibles st Cibles 2 Exemples Caegorte: OVERFLOW RIGHTS_ATTACK Contente: Mots-Clesz Définition Règles ; IMARMAR41911.111/VZIMMY Inteneka Farix,ftees:: Résultat % detected Cibles .1611;181914011^10{1{Iellfflp.i. Cibles Cibles 2: Exemples 6 Catégorie: VIOLATION Oblectit RIGHTS_ATTACK Contexte: Mots-Cles: Définition 73333,11^11.6011MMIR Régies ,551,19^10M1^1010 Résultats detecteci Cibles Cibles t Cibles 2 : Exemples .1.. 7 Catégorie: OTHER Oblectit RIGHTS_ATTACK Contexte: Mots-Clesz DèfInitIon Monze/P1WIPIMIIIM ATTAQUE de type X détectée pour permettre à un user ou un groupe de user,ou profil user de prendre un privilege sur une ressource un fichier un répertoire une imprimante Règles Faux-Avais Résultats .71.115^215916671.1^1^16 detected Cibles Cibles I Cibies 2: Exemples '11/DZIMMODSMIOIM Attack_Privilege.ICMP.User Deteeled snort.Rules338 $3 Classification Attempted User Privilege Gain ICMP 8 3.6 RIGHTS SUSPICIOUS Catégorie GAIN oblectif: RIGHTS_SUSPICIOUS Contexte: Mots.Cltee: Définition Rtigtea Wei de Faux-Amis Rdeuttate z detected Clbtee Cibles I Cibles 2 Exemptes 9 Catégorie: VIOLATION Oblectit RIGHTS_SUSPICIOUS Contexte:. Mots-C les Définition ACTIVITE SUSPECTE de type X détectée sur les droits sur une ressource ou sur un privilège Règles intelditz Faka-euris Rdeultata leeraMMIIIMMISAIMISUM. detected Cibles Cibles if Cibles 2 Exemples 0 Cale:soute: OTHER °blé:bote RIGHTSSUSPICIOUS Conteste; Oilots,Cleaz Définition Règles ; 11111618111MIMIMI1111111 Faux-Ales .:-: Résulitate detected Cible: Cibies Cibles a Exemptes 1 17 RIGHTS_VULNERABILITY Catdeortez BRUTE FORCE Objectif, RIGHTS_VULNERABILITY Contextes Mots-1^--les7s. Définition Règles Intemide Fatee-Aersie Résultats detected Cibles Gildes Cibles 2 Exemptes 2 Catégortez BYPASS 0 biectif: RIGHTS_VULNERABILITY Contexte: Mots-C les: Définition WeeleelneelleSOIOMMIS Règles Pnteteee Résultats detectecl Cibles Cibles 1 Cibles 2: Exemples 3 Catégorie:. DIRECTORYTRAVERSAL Oblectit RIGHTS_VULNERABILITY Contexte:. Mots-Clesz« Définition Règles inteidits Faux-Amis : Résultats detected Cibles 1/0DMEOletelelIDMOdelflOfflelt, Citties t Cibies 2: Exemples ;. 4 Catégorie: DOS Oblectit RIGHTS_VULNERABILITY Contexte:. Motu-Cies: Définition z Règles Inteidite Faex-Anig$ Résultats z detectecl Cibles; Cibles Cibles Exemples z CatdeprIez EVASION Oble RIGHTS_VULNERABILITY Contexte Mots-Cies:. Définition z Règles 101SAMMOMMIMMOMMIMI. Inients Faex-Amie Résuitata detected Cibles Cibles 1: Cibles 2 Exemples 6 Catégorie: GAIN °bloc:tif: RIGHTS_VULNERABILITY Contexte:. Mota-C initIon Règles intetet$ Fatex-lurà Rdsuttats detected Cibles Cibles 11. Cibles Exemples 7 Catégorie: INFORMATIONGATHERING Obiectit RIGHTS_VULNERABILITY Contexte: MotaCteaz Définition Règles 1/deete Faux-Avais Résultats detected Cibles Cibles t: Cittes2; Exemptes 8 Catégorie INJECTION Oblectif: Contexte: RIGHTS_VULNERABILITY Mots-Cles: Définition -fflSeeralefleMAIIIMAIM VULNERABILITE de type X détectée sur le service d'authentification la connexion, le user; le pawd Règles IMeidite Faux-Ain4s Résultats naMieniOMMIODAteM detected Cibles Cibles lt Cibles 2 Exemples 9 Catégorie: OVERF LOW Oblectit: RIGHTS_VULNERABILITY Contexte: nitota-Cleaz Définition Règtes linteeflit$ Fatee-Atnie.:-: Rdseatitate detected Cibtesi Cibles t Client 2,: Exemptent 0 Catégorie: VIOLATION Oblectif: Contexte: RIGHTS_VULNERABILITY Mots-Cleaz Définition Règles lebets Fae-Arais Résultats detected Cibles A116^11818-31MMORMIefeat Cibles Cibles 2 Exemples 1 Catégorie; WORM Oblectit: RIGHTS_VULNERABILITY Contexte: Mots-Glas: Definition Règles 'z leterdita Fam-Aimie Rdeuitate detected Cibles Cibles Cible* 2 Exemples 2 Catégorie: OTHER obleclie RIGHTS_VULNERABILITY Contexte:: Mots-Cies:: Définition z. Régies z Weide Fate,,Anzi$ Résultats detecte Cibles ables t: *hies 2: Exemptes 3 18 SYSTEM_ACTIVITY Catégorie: CONNECTION Obloctilz SYSTEM_ACTIVITY Contexte: Mots-Clesz, Connexion, tunnoted. established, Définition allMAIMMIWIMINIMM111. Connexion d'un paquet ou d'un composant d'un protocole sans passer par un service d'authentification Régies inteffets.:' Faux-Amie:: Authentication, session Résultats Sei@Ceee' Connexion avec succès Dee» z Connexion refuser Eirme : Une erreur sur le service qui gère la connexion Cibies Cibles a: Exemples Monitoring_Activity.ICMP.Packet_Accepted nagios Rules78 Host $3 Oct 28 11:42:33 shadowcat nagios:11-10ST ALERT: rcts2,UP,HARD,2,PING OK Packet loss = 0%, RTA = 0.26 ms 4 Catégorie: FORWARD Oblectif: SYSTEM_ACTIVITY Contexte: etiote-Cles: Forward, g»oket, dent/; traffie, dropped' blooked, perrnitted, allowed, rejected, bad Définition Réservé pour modéliser uniquement le relayage d'un flux, d'un protocole, d'un host ou de son contenu comme un paquet, un message, fichier, une donnée, etc... Régieu interdite: Faux-Amie:. Connection, send, receive Rdeultate fRIMMIEMIMMII^11M14 fie; le relayage est accepté Denied : le relayage est refusé Eme : présence d'une erreur sur le service du relayage Cible* : Deux types de cibles peuvent être analysés et relayés : des flux ou des hosts : Si la CIBLE 1 est un type générique c'est HOST ou s'il spécifie un équipement autorisé dans la liste, cible 1 peut etre = firewall, un ids, un routeur, un prox Cie« : Si le service de relayage concerne en CIE3LE 1 un flux Alors on utilise la valeur "traffic" Cibles 2: ce que le host manipule comme un paquet, un message, fichier, une donnée, etc... Exemples contivity.rules 309 IP redirection failed 19 Jan 10 10:31:41 clnomadm 9482 01/10/2005 10:38:19 tEvtLgMgr 0 : IP Redirector [13] RtTabDelete(0.0.0.0 255.255.255.255) failed with status -1 netasq.rules 116 NetAsq Firewall : Packet dropped 5 27 Sep 14:16:45 192.168.11.81 id=firewall time="2004-09-27 09:56:14" fw="asq-dev" tz=+0000 startime="2004-09-27 09:56:14" pri=1 ruleid=1 srcif=Ethernetl srcifname=in ipproto=tcp proto=527 src=192.168.10.101 srcport=63049 srcname=exadev dst=192.168.10.81 dstport=527 dstname=Firewall_in action=block msg="fil ter alarm" logtype="alarm" 6 Catégorie: READ ()blettit SYSTEM_ACTIVITY Contextez Mots-Cieez. Read, open' file' data Définition LECTURE d'une ressource de services ou de données système. Règles Weifelike Fans-mi.% Receive, control Relaulitate z SIMMAMARRMIOMAIRMall. SuCCee ; Lecture réussie de la ressource &Mi: La lecture de la ressource rencontre une erreur de fonctionnement Cibles, ; Cibles 1 Cibles 2 Exemptes z system_wmi.map 1778 Log file opening failed 7 Catégorie: WRITE Oblectit SYSTEM_ACTIVITY Contexte: Mots-Clesz Write, create, file, data Définition Ecriture réussie sur une ressource ; un fichier, une base de donnée, un disque, une mémoire Règles Faré-Aeaki : Control, modification d'un fichier ConfFile Résultats Succese.:'Ecriture réussie d'une ressource &mi: L'écriture sur la ressource rencontre une erreur Cibles ; Cibles 1' Cibles a: Exemples epo_db.map 1569 Error white trying to create activity log file. epo_db.map 1605 Error writing to log Catieorte: RECEIVE Obiec tif: SYSTEM_ACTIVITY Contexte 8 Mots-Cleaz .AL Receive, message, request, response, Racket Définition RECEPTION d'un objet communicant de type mail, paquets, trames, requêtes émis émis d'une commande, d'un composant, d'un service, d'une application, d'un processus, d'un driver, d'un protocole, d'un OS ou d'un user Règles Intenta Fett*-Atnia Résultats StieCeeSe Reception réussi d'un objet &Mit: la reception de l'objet rencontre une erreur Cibles Cibles t Cibles 2 Exernples apache_pltRules23 Web server: request received 100 Continue ironmail.rules 68 Message received 5 Nov 28 11:32:00 193.43.93.71 11282006- 11:32:0012115211933101100IMessage received. Received IP From <> To Route IDomain Route Host = Exemptes bluecoal_system.rules 384 DNS service restored dell-om.rules 818 ESMP internai event - AC power restored esmp.ru es 111 ESMP : restore successful! 1 Catimarte: CONTROL Obiectif: SYSTEM_ACTIVITY Contexte:. Mots-Cies °perditions', round, '" net round, test, verify Définition VERIFICATION d'une ressource Régies ;. inieedike Faux-Amie Résultats Seseess Vérification réussie d'une ressource Evier : Erreur dans la vérification de la ressource Cibles z de11101118^1111*»M». Cibles Cales 2 Exemptes screenos.Rules980 NetScreen: interface up Jun 16 15:32:33 192.168.15.15 ns208: NetScreen device_id=ns208 system-notification- cisco-pix.rules 669 Testing firewall interface 2 astaro_v5.Rules189 $4 INFO-150 : Root partition mounted at / is filling up - please check astaro_v5.Rules204 $4 INFO-151 : tmpfs partition mounted at /opt/tmpfs is filling up - please check astaro_v5.Rules219 $4 INFO-152 : secure application parlai° 3 3.9 SYSTEM CONFIG Catégorie: ADD Obientif; SYSTEM_CONFIG loti-Cids: Configuration, add, configuration file, created, inatalled, inserted Définition WCNIIIRISIMISAMIISOM AJOUT de la configuration d'une commande, d'un composant, d'un service, d'une application, d'un processus, d'un driver, d'un OS, d'un host ou d'un cievice ou encore d'un réseau Règles Weide Fatee-Arieà.:- Reltataiitate SiecgeSS:: La configuration a été correctement ajoutée &me : La configuration n'a pas pu être ajoutée ou une erreur s'est produite lors de son ajout. Cibles Cibles Cibles a: Exemples linux.Rules335 Configuration file installed Nov 30 14:33:00 exaark /usdamanagerd/amanagerd[18217]: Install configfile (cmd 4) cisco-switch.rules 1333 Device added 106 Jun 1 14:52:16 R2DRP2RTRK21 1028220: Jun 1 12:54:18.447: %USB_HOST_STACK-6-USB_DEVICE_CONNECTED: A Full speed USB device has been inserted in port stonegate.rules 194 New configuration installed 11 Nov 9 13:15:31 17.16.23.3 "2006-10- 03 16:11:56","17","1.1.0.16","Authentication","Nlotification","New configuration successfully installed",',''''"138412032" "stonegatefw Single Node",""''"2006-10-04 10:18:06","Firewall", ',"4864924205096894481", ' Catégorie: DELETE Oblectit SYSTEM_CONFIG 4 Afore-Ctés: Configuration, delete, remove, configuration file Définiition SUPPRESSION de la configuration d'une commande, d'un composant, d'un service, d'une application, d'un processus, d'un driver, d'un OS, d'un host ou d'un device ou encore d'un réseau Règles z. -111Matereas- ffitetdite Fattx-Amie.: Résultats St4ect=',:' La configuration a été correctement supprimée Emre: La configuration n'a pas pu être supprimée ou une erreur s'est produite lors de sa suppression. Cibles Cihlss t Cibles 2 Exemples isa2004 rules 1703 Address removed from interface table 95 lucent.rules 1286 Delete Proxy Table Entry 108 Catégorie: MODIFY Oblectitz SYSTEM_CONFIG Morst-Cids: Configuration, modify, modification, configuration file, change Définition MODIFICATION de la configuration d'une commande, d'un composant, d'un service, d'une application, d'un processus, d'un driver, d'un OS, d'un host ou d'un device ou encore d'un réseau Règles z. Unetelies Faux- Amis Rdsulttats Sexceee:: La configuration a été correctement modifiée Eget : La configuration n'a pas pu être modifiée ou une erreur s'est produite lors de sa modification. Cibles cites Exemptes z: cisco-fwfules 2026 System config modified 150 Nov 20 17:01:24 pix2.xxx.com Nov 20 2006 15:47:14: %PIX-5-111004: 172.22.1.125 end configuration: OK cisco-switch.rules 853 Interface state changed 65 Feb 20 09:53:51 R1 G-SYNRTRH 2413: .Feb 20 09:53:07.505: %HSRP-6-STATECHANGE: FastEthernet0 Grp 101 state Active isa2004.rules 1430 Web configuration modified 6 Catégorie: UPDATE Obiec:tif4 SYSTEM_CONFIG Mots-Cids: Configuration' update, Up2Date, pattern, synchronization, service, application, proteus, driver, hoetDéfinition MISE A JOUR ou SYNCHRONISATION d'un service, d'une application, d'un processus, d'un driver, sur un composant de type host, partenaire Règles leteedite; Faux-Amie Résultats Sui eu Le service, l'application, le processus, le driver a été correctement mis à jour (ou synchronisé). Eu': Le service, l'application, le processus, le driver n'a pas pu être mis à jour (ou synchronisé) ou une erreur s'est produite lors de sa mise à jour (ou synchronisation). Ciblee Cibles t caltes a Exemples 6165.11110.1.91Hrieff alteon_webswitch.rules 123 Config synchronization successful ipso.rules 455 Cluster synchronization error mcav.rules 21 Antivirus: update failed 310 SYSTEM INFORMATION Catégorie: CONTROL ()blettit SYSTEM_INFORMATION 7 Contextez. Mots-Cles:: ADDAMMAMIUMMIR Information, fouri, valid, invaiid, normal, service, application, process' oeinition Informations indiquant l'état pour un service, une application un processus, un driver, sur un composant ou un device ou un host ou un réseau Règles -ellMll»5551IMID51.1.901( /Merde User en ciblel ou en cible2 Une ressource utilisateur en cible2 Fate-Ami Rdstalitats Vert: Informations indiquant un état valid pour un service, une application un processus, un driver, sur un composant ou un device ou un host ou un réseau Informations indiquant un état invalid pour un service, une application un processus, un driver, sur un composant ou un device ou un host ou un réseau efee- Informations indiquant une notification sur un service, une application un processus, un driver, sur un composant ou un device ou un host ou un réseau Cibles Cibles Host, Application, Service Cibles a Exemples 8 DNS server notify malformed 4 Jul 23 10:43:24 exademo named[4921]: notify question section contains no SOA cisco-fierules 955 Primary unit configuration corrupted cisco-fw.rules 1177 Route not existing 88 Apr 04 2005 23:34:41: cY0PIX-6-110001: No route to 10.200.2.10 from 10.115.7.1 9 Catégorie: THRESHOLD obiectit SYSTEM _INFORMATION Contexte:. Mots-Cles: Information, timeout, full, limitation, exceeded' memory, space* etorage' capacity' ineufficient Définition Informations concernant des dates, des connections, des supports de stockages qui DEPASSENT un seuil Régies Intexiits User en ciblel ou en cible2 Une ressource utilisateur en cible2 Faux-Amis Résultats Expie(' Résultat Informations indiquant l'expiration d'une version Exceedad Informations indiquant une utilisation DEPASSEE ou HAUTE de la CPU, du disque, de la mémoire ou du Power Nvigeta# Informations indiquant une utilisation normal des seuils prévus de la CPU, du disque, de la mémoire ou du power Cibles Cibles Host, Application, Service 2: CPU, Disk, Memory, Power Exemples z: 0 cisco-pix.Rules200 Embryonic connection limit exceeded Dec 22 15:55:33 pix %PIX-4-407002: Embryonic limit for through connections exceeded 243/100. 208.252.69.162/55452 to 12.33.8.58(192.168.250.58)/80 on interface outside astaro_y4sules 643 Astaro: Not enough free space on harddisk 45 WAR 100 Not enough free space on harddisk - please check 311 cisco-switch.rules 185 Insufisant memory 1 SYSTEM_ATTACK Catelsorte: BACKDOOR Oblec SYSTEM_ATTACK Contextezr. Mots-Clesz Dellnitlen Règles interdite Faux-Aerzie.:.: Recaulitata detected Cibles z. Cibles 1 Exemples 2 Catêuorte: BOUNCE Oblectif: SYSTEM_ATTACK Contexte: Mots-C tes: Définition Règles Iplaiete Faux-Amie : Résultats detected Cibles Cibles 1i : Cibles 2 Exemptes 3 Catégorie: CONCEALMENT °blettit SYSTEM_ATTACK Contexte: Mots-fies: DèfInition Règtes 11.1161-11WROZ^SAMMAS, intente:: Faux-Ai/nia .:-: Rdstaltats detecteci Cibles Cibles t Cibles 2 Exemptes 4 Catégorie: DOS Obiec SYSTEM_ATTACK Contexte: Mots-Clesz Définition Règles z efflelIDIMNIME121191111M109l, /Mente Résultats z detected Cible-te Cibies 2: Exemples z Catégorie: DDOS Obiectif: SYSTEM_ATTACK Contexte:: Mots-Cies: Définition Règles z ipteeteis Résultats detected Cibles z felllf1DIMMIDDEMIMPAIll Cibles 2: Exemples 6 Catégorie: Oblectitz SYSTEM_ATTACK DIRECTORYTRAVERSAL Contexte: Mots-Cies: Définition Règles .1eStlfell111MOM irateelits Résultats z detected Cibles Cibles Cibles 2 Exemptes 7 Catégorie: EVASION SYSTEM_ATTACK o tèr: Contexte:: Mots-Cies:: Définition Règles Inteiciaa Fakee-Asniz.:-: Résultats detected Cibtee Cibles t z Cibles 2: Exemples 8 Catégorie: GAIN Oblectit SYSTEM_ATTACK Contexte:: Dota-Clea Définition Règles laiteireitta Faux-Am% Résultats detected Ciblee Cibles t Cibles 2 Exemples 9 Catégorie: HIJACKING °blettit SYSTEM_ATTACK Contexte: Mots-Cles: Définition GAIN de PRIVILEGE d'un admin ou d'un user sur une ressource Règles inteedite Faux-Amie Rdsultata z detected Cibles 1116VMDDIMM11112-11123.0. Cibles *tees 2 Exemples 0 Catégorie: 0 i tit SYSTEM_ATTACK Contexte:, Mots-Cles: Définition Régies inteedita Faux-Amis Résultats d etecteci Cibles Cibles 1' Cibles 2 Exemples INFORMATIONGATHERING 1 Catégorie: INJECTION Obiectif Contexte: Mots-C ies: SYSTEM_ATTACK Définition Règles ; Fatex-eunàz: Résultats d etectecl Cibles "MeeffllIRMILIIMPLIS1^16.6. Cibles 1 Cibles 2 Exemples 2 Catégorke OTHER Oblectif: SYSTEM_ATTACK Contexte: Mots-C Définition Règles Intente -:. Faka-Aertie Résultats detectecl Cibles Cibles Cibles 2 Exemples 3 Catégorie: OVERF LOW °blettit SYSTEMATTACK Contexte:: mots-e..teaz Définition Régies letetelita Faka-Aprzi.e Résultats detectecl Cibles, 110-EMII(MDMI11141eleferell Cibles I ellen 2 Exemples 4 Catdeorte: PHISHING °blettit SYSTEM_ATTACK Contexte:: Définition Règles iMeezeee:: Fatte-A8niez: Rdeuitate detected Cibles Cibles1 Cibles 2: Exemples Catilgorke PHYSICAL Obi« tif: SYSTEM_ATTACK Contexte:. Mots-C les: Définition Régies iretetcli Fate-Afruà.:-: Résultats detecteci Cibles eateeMestelememesseam. Cibles Exemples 6 Catégorie POISONNING Obiectif: Contexte: mots-cies: SYSTEM_ATTACK Définition Règles leetets Faux-dore Résultats z detecteci Cibles Cibles Cibles 2 Exemples 7 Catégorie: PROTOCOL Oblectit SYSTEM_ATTACK Contexte:: Mots-Ctesz Définition Régies z Faux-4tortiz.:-: Résuitats detectecl Cibles Cibies Ce« Exemples 8 Catégorie: SPOOFING b tif: SYSTEMATTACK Contexte: Mots-Clesz Définition Régies 41D12.11-MMIDD^ leteiclike Farte-Afre4 Résultats detecteci Cibles Cibien *hies 2 Exemples 9 Catégorie: STEAL Oblectit SYSTEM_ATTACK Contexte: Mots-Clesz Définition Règles inteedite Fate-Arnie Résultats detected Cibles Cibles Cibles2; Exemples 0 Catégorie: VIOLATION biectit Contexte:. Mota-Clete SYSTEM_ATTACK DÉ:finition Règles Inteidite Faux-Anie Reitaultate detected z Cibles Cibies 2 z- Exemptez: 1 112 SYSTEM MALWARE Catdeorte: P2P Obi« tif: SYSTEMMALWARE Contexte: Mots-Cies: Définition Régies Inteedite Fa4e-M-lie Résultats detected Cibles Cibles Cibles 3: Exemples 2 Catégorie: SPAM Oblectit SYSTEM_MALWARE Contexte: Mots-Cie-az Définition : Règles bUetdite R de ultate detectecl z Cibles 1 Cittles 2 Exemptes 3 Catégorie: SPYWARE oblectitz SYSTEM_MALWARE Contexte: Mots-Clesz Définition Règles ivienies Fei-Aeni,s Résultats detected Cibles Carle$ 1t #0^2951/80M1MM Cibles 2 Exemples Catégorie: TROJAN Objectif: SYSTEM_MALWARE Contexte: Mots-Cies: Définition Régies lintegiits Faux-Anie : Résultats detectecl Cibles 2 4 Cibles Cibles 2: Exemples .1 Catégorie: WORM Oblectit SYSTEM_MALWARE Contexte: Mota-Cleaz Définition Règiea MODOMMIVAnDIMIM Inteselike Fare-Antà Rdeuttata detected Cibles Cibles 2 Exemples 6 Catégorie: OTHER oblectêt SYSTEM_MALWAR E Contexte: Mots-Ctesz, Dèfinition 7.1,1^3311311A111DMIII2 MALWARE détecté sur le SYSTEME de type X sur une commande, une application, un service, un processus ou des paquets Règtea Rdstalitats detectecl Cibles; Cibles Cibles Z: Exemples 7 1/3 SYSTEM_SUSPICIOUS Catégorie: BOUNCE Oblectit SYSTEM_SUSPICIOUS Contexte: Mots-Clea'z: Définition ACTIVITE SUSPECTE sur le SYSTEME de type X détectée sur une commande, une application, un service, un processus ou des paquets Règles tedeofge Fatee4ovie Rèsullets detected Cibles 7981116i MIN MS Cibles 1 Cibles 2 Exemples 8 Catdeorie: CONCEALMENT Oblectit Contextez. SYSTEM_SUSPICIOUS Mots-Clee'z Définition z. Régies /Miaules ; Fatte-Amis Reetittate z detectecl Cibles. Cib' tes Cibles 2: Exemples 9 Catégorie: DOS Obiectit SYSTEM_SUSPICIOUS Contexte:. Deinition Règtes z IMetas Fat-Ai .: Relauttats detected Cibles Cibles Cibles 2 Exemptes 0 Catégorie: DDOS Qblectif: SYSTEM_SUSPICIOUS Contexte: Mots-Cles: Définition Règles Priteaclita .:- Far-Afree Rdsuirtats detected Ciblea Cibles t Cibles 2: Exemptes 1 Catégorie: EVASION Oblentlf: SYSTEM SUSPICIOUS Contexte: Mots-Cies: Définition ATTAQUE de type X détectée pour permettre à un user ou un groupe de user,ou profil ou un service de prendre la main d'éxécuter une commande un service une application un host ou un composant Règles Faux-Avnie.:: Rdstiltate 11,11MDEAMMeeW detected Cibles Cibles Cibles a: ExeMples Catégorie: GAIN Oblectif: 222 SYSTEM_SUSPICIOUS Contexte: itots-Ciea: 4fInition Règles Ingeidge Résultats d etectecl Cibles Cibles t Cibles 2 Exemples 3 Catégorie; INFORMATIONGATHERING Obiectit SYSTEM_SUSPICIOUS Contexte: Mota-Clese: Dênnition Règles ledeiclita Fake-Atre4 Reauttate detected Ciblez' Cibles lt Cibles 2: Exemples 4 Catégorie: INJECTION Obiectit SYSTEM_SUSPICHDUS Contexte: Mota-Ctea: Définition Régies 10AMAlll1MIMIIMMIMOM leude :: Faux-Aar Résultats detected Cibles Cibles Cibles az Exemples Catégorie: OVERF LOW Oblectit SYSTEM_SUSPICIOUS Contexte: Mots-Clesz. Définition Règles leleuete Faux-Amie Résultats -^-----^--^----^^-AIIIIIIIMMIL detecteci Cibles z. Cibles 1' Cibles 2 Exemples 6 Catégorie: SPOOFING Obioctif: SYSTEM_SU SPIC IOUS Contexte: Mots-Cies: Définition Régies intiediee .Far: -A Rdeultata detected Cibleo Cibtes Cibtes Exemptes 7 Catégorie: VIOLATION Oblectit Contexte:. SYSTEM_SUSPICIOUS Mots-Clesz DèfInition Règles intetdika :- Faux-Anie Rdeuktats detectecl Cibles z 11M61111111161MIIII1M4111Melle. Cibles t Cibles 2: Exemples Catégaele VIRUS Oblectit 228 SYSTEM_SUSPICIOUS Contexte: Mots-Clesz Définition Règles z latere:es Fere-Amie Résultats detectecl Cibles z Cibles 1 Cibles 2: Exemptes 9 Catégorie; OTHER Obiectif: SYSTEM_SUSPICIOUS Contexte:. Motu-Cies: Définition Règles 1fflefflablAVAIMUMIU 111^111102611II.MORMEMOROM tate/dits; Faux-Ms .:: Rdeulitate z detected ,11^IDefeffleffAMMeralSeffeffer-Y Cibles z Cibles Cibles 2 Exemptes 3.14 0 :SYSTEM_VULNERABILITY Catégorie: BOUNCE Obier tit Contextez Mots etesz D oe finition rz VULNERABILITE sur le SYSTEME de type X détectée sur une commande, une application, un service, un processus ou encore du réseau ou de ses paquets Reigtoe 1Weaclik4 Farte--Aaris Résultats detected Clbles Cibles / Cibles 2 EXQTYIL:blies SYSTEM_VULNERABILITY 1 Catéeorle: BYPASS QbieenstifL SYSTEMVULNERABILITY Contexte: Mots-Cies: Définition Règles linteedite Fare-Aenie Résultats detected Cibles z Cibles 1 Cibles 2 Exemptes 2 Cateigorle: CONCEALMENT «tif: SYSTEM_VULNERABILITY Contexte: Nlota-Clesz Définition z Règles Iffeeedits Feux-Amis Résultats z detectEd Cibles z Cibles Cibles 2: Exemples z 3 Catégorie: DDOS Obiez SYSTEM_VU LN ERABI LITY Contexte: Mots-Ctesz Detnittan Règtes eellenelleeleffleW Intefeia Reinuittats detected Cibles Cibles 1: Cibles 2 Exemples 4 Catégiarte: Obientit DIRECTORYTRAVERSAL SYSTEM_VULNERABILITY Contexte:. Nlots-Clesz Définition Règles nleaMIDADMIAM Intatelge: Faux-Annie:: Résultats detected Cibles Cibles 1 Cibles 2 Exemples CatElgorte: DOS Oblectit SYSTEM_VULNERABILITY Contexte: Nlots-Cles: Delnition Règles Inteedite Faux-Ami$ Résultats detected Cibles 117#110EMOMDF6661(«Z». Cibles t Ciiales 2: Exemples 6 Catégorie: EVASION Obleotd: SYSTEM_VULNERABILITY Contexte: Definition Regtee inteedge Fatex-Avais : Résultats detected Cibles Gibier I: Cibles 2: Exemples rz 7 Catégorie: GAIN Obleceit SYSTEM_VULNERABILITY Contexte: Mots-Cles.: Définition Règles inteedite Fare-Arees Rdsuktats detected Cibles Cibles I : Cibles 2 Exemples 8 Catégorie: Oblectit INFORMATIONGATHERING SYSTEM_VULNERABILITY Contexte:: Mots-Cles; Définition Règles z TIJAIDAIMUMMAIMMIll Inteedite .:- Fake-Amis Relsemitats detected Cibles 111312MIEMR1116ffle abe3 z Cibles 2: Exemples 9 Catégorie: INFORMATIONLEAK Oblentit SYSTEMVULNERABILITY Contexte: Mots-Cles: Définition Règles 919,111121161140114MM1 Rdsultats z detected 76111111091616116.199111MISMS Cible% Cibles Cliates a Exemples 0 Catdeorle: INJECTION Obiectit SYSTEM_VULNERABILITY Contextez. Mots-Clesz Delnition Règles z intetee.:' Fata-Arnie::: Rèsuitats d etected Cibles dies I Cibles 2: Exemples 1 Catd9orte: OVERFLOW Oblectit SYSTEMVULNERABILITY Contexte:: Mots.Clea: DelnitIon Règles inteindite ti Faux-Amie .:: Relisuttats detected Ciblas Cuites 1; Cibles 2: Exemples 2 Cati:gode: P2P Obiectil: SYSTEM_VULNERABILITY Contexte: Mots-Cites: Dèfinition Règles Przbeffde, Fate-Arnis Résultats detected Cibles Cibles /: Cibles 2 Exernplete 3 Cateigodez PHYSICAL Oblectif: SYSTEMVULNERABILITY Contexte: Mots-Cies: Delnition Règles Faux-Amie Résultats detected Cibles -119,9111MMOSIMMOMMIMS. Cibles Cibles 2 : Exemples 4 Catieriez POISONING ©b leretit Contexte Mote-Ctes: SYSTEM_VU LN ERABI LITY Définition Régies z: Intedite Faux-An-es .:-: Resuitats detected Cibles Cibles Cibles 2: Exemptes Catégorie: PROTOCOL Obletretitz SYSTEM_VULNERABILITY Contexte:. Mots-Cies:: Deifinition Règles z. Inteeee; Fate-Anzie Résultats detected Cibles Cibles t Cibles 2: Exemples 6 Catégorie: SPAM Oblectif: SYSTEM_VULNERABILITY Contexte: Mots-Clesz Définition Règles z Inteedi,te Petri-61g Résultats detected Cibles Cibles I Cibles 2: Exemples 7 Catégorie: SPOOFING Obientif; SYSTEM_VULN ER ABILITY Contexte: Mots-Cies:. Définition Régies -IMMOMMISIMIR^0.0 leude Fatex-Sorie Résultats detecte d Cibles Cibles Cibles 2 Exemptez: 8 Catégorie: SPYWARE Obientit Contexte: SYSTEM_VU LN ERABI LITY Mots-Ciesz Définition Régies Esta-Amee Résultats : detected Cibles Cibles 1 Cibles .a Exemples 9 Catégorie: STEAL Obientif: SYSTEM_VULNERABILITY Contexte: Mota-Cleez Définition z Règles letteentee.: Fartx-Amie Rdeuttate detected Cibles Cibles / Cibles 2 Exemples z 0 Catégorie: TROJANObiectif: Contexte ellots.Cleaz SYSTEM_VULNERABILITY Definitlan Règles Ferx-Amis Résultats detected Cibles Cibles t Cibles Exemples z 1 Catégorie: VIOLATION Obleatit SYSTEM_VULNERABILITY Contexte: Mots-Clesz Définition, _Règles 4.113.331111DEMMEllelltIlll. ledeeeies Fat, -Amis Relsultats detected Cibles Cibles Cibles 2: Exemptes 2 Catégorie: VIRUS Obiectif: SYSTEM_VU LN ERABI LITY Contexte:. Mots-Cteez Définition Règles Fate-Aota z: Résultats detected Cibles Cibles I Cibles 2 Exernplea 3 Catêtiorie: WORM oblectit SYSTEM_VULNERABILITY Contexte: Mota-Ctee: Dellnittorb Règles Inteodite Faux-Amis z: Resulltats detected Cibler Cible* .e cimes Exemples 4 Catégorie: OTHER Oblectit SYSTEM_VULNERABILITY Contexte: Mots-Cies: Définition Règles Intel cli Fate-Mv.e Résultats detected Cibles 11111111MIMMOMOMMM16 Cibieee 1 Cible* 2 Exempte% Monitoring_Activity.OS. Dente niksun_netdetector_db.map 152 A system call was detected 4 Modélisation des CIBLES Figure 21 256 objects attributs Equipemen NetWor ts Protocoles Group Services Application Executable Attribut s s User Attributs Attributs Systeme Réseau Attributs Secuntte Attribut s Hardwa re générique Host Command Service Protocol Account Networ k SysAttributs UserAtt Credential Application Group Descritpio n NetworkA HardAtt ttnbuts i nbuts Host Antivirus ARP AccountGr Account Traffic Antivirus Table I CPU ACL Command Attach Cluster Memor Chat AccountHost Interface Conf file Certificate Credential Process Firewall IDS Modem Printer_De vice Proxy Router Switch Password APC ApplicationPayme nt Audit 1 Multimedia Chat 1 Audit Database Management Packet Trap Tunnel AccountService Database Admin DHCP Anonymous DNS oup AdminGrou p ServiceGro up Port VLAN VPN Guest DHCP Ethernet FTP DNS Data Director y File Messag e Reply Reques URL. Addres s ACL SecurityTools GUI ICMP Domain IP LDAP MAIL Management Licence Log_file Method Patch Pattern Queue Registry SysData SysDirector SysFile Version NFS P2P PinterProtocol PUP RIP RPC SSH SSL TCPIP TELNET Time UDP VLAN VolP VPN WEB EAS rir IPSEC LDAP MAIL Managemen Multimedia NFS OS P2P P2P PinterProtoc ol DVI PUP RPC SecurityTool s Service SSH SSL SysAuth TCPIP 257 Wireless TELNET Time VolP VPN WEB Wireless Localisat ion ontologiq ue cible cible 1 cible cible cible 1 cible 1 cible 1 cible 1 cible 2 cible 1 cible 2 2 cible 2 cible 2 2 wrz cluster (state,como nent,param eter) cible 1 juste pour gain toujours en cible 2 sauf si en cible 1 on précise un compte si pas de précision OS 8 4.1 Cibles pour « AUTHENTICATION » 4.1.1 Modélisation de l'authentification Figure 22 Services d'authentification Cible ls Définition spécifiques Application Générique pour modéliser les services d'authentification d'une application utilisateur OS Générique pour modéliser tous les services d'authentification d'un OS Linux, Unix, AIX. ApplicationPayment Générique pour modéliser les services d'authentification d'une application de paiement électronique Multimedia Générique pour le service d'authentification des outils multimedia Database Générique pour le service d'authentification des bases de données (oracle, sql) Domain Générique pour le service d'authentification des domaines Mcrosoft ou autres (Ne pas mettre OS) Management Générique pour le service d'authentification des outils d'administration Audit Générique pour le service d'authentification des outils d'audit Antivirus Générique pour le service d'authentification d'un Antivirus SecurityTools Générique pour le service d'authentification des outils de management de la sécurité HOST Générique pour modéliser tous les services d'authentification d'un d'un équipement non détaillé dans la liste APC Générique pour le service d'authentification d'un onduleur FireWall Générique pour le service d'authentification d'un firewall Proxy Générique pour le service d'authentification d'un proxy Router Générique pour le service d'authentification d'un routeur IDS Générique pour le service d'authentification d'un équipement de détection d'intrusion Modem Générique pour le service d'authentification d'un équipement WAM Modem Switch Générique pour le service d'authentification d'un équipement réseau SWITCH SysAtuh Générique pour modéliser un système d'authentification non défini ci-dessous (kerbero, radius) Chat Générique pour le service d'authentification des outils de messagerie instantanée LDAP Générique pour le service d'authentification de la famille LDAP SSH Services d'authentification via le service SSH SSL Services d'authentification via le service SSL WEB Générique pour les services d'authentification via le service http, HTTPS 9 Comptes utilisateurs pour l'authentification Account Admin Anonymous Guest AccountHost AccountService 0 Attributs et données des comptes utilisateurs Certificate Crederitial PasSwOrd Liste des possibles pour les mouvelments d'authentification AUTHENTICATION ACTIVITY Lo- n S sAuth Account success Logout Antivirus Acco untG roup failed Lock UPS tuntH Acc oso error Audit AccountS ervice Chat Admin Database Anonymo us Domain Guest ESMP FTP Connection ou déconnection d'un IPSEC COMPTE utilisateur auprès d'un service d'AUTHENTIFICATION LDAP MAIL Cible 1 : Service d'authentification PKI Cible 2 : Com ite utilisateur PUP Cible non vide SSH SSL TELNET UpdateServic e VolP VPN WEB WIRELESS A .. ication ApplicationPa ment GUI Multimedia Mana -ement Securi Tools Host Firewall IDS Prox Router Switch AUTHENTICATION ACTIVITY BACKUP S sAuth Account success RESTORE Antivirus Ac countG roup failed UPS AccountH ost error Audit AccountS ervice Chat Admin Database Anonymo us Domain Guest ESMP Certificat e FTP ConfFile Restauration ou IPSEC Credentia sauves arde d'un I 1 compte, UTILISATEUR ou de ses propriétés comme son nom, son mot de passe, etc... LDAP Password MAIL Cible 1 : Service d'authentification PKI du compte sauvegardé ou restauré PUP Cible 2 : Comote utilisateur SSH SSL TELNET UpdateServic e VolP VPN WEB WIRELESS. A.. lication ApplicationFe a ment GUI Multimedia Mana-ement Securi Tools Host Firewall IDS Prox Router Switch AUTHENTICATION CONFIG ADD S sAuth Account success DELETE Antivirus Ac countG roup failed MODIFY UPS ostAccountH error REPAIR Audit AccountS ervice Chat Admin Configuration du service Database Anonymo d'AUTHENTIFICATION commeun us COMPTE UTILISATEUR ou un MOT DE PASSE Domain Guest ESMP Certificat e I FTP ConfFile Cible 1 : Service d'authentification du compte configuré IPSEC credential LDAP password Cible 2 : Compte MAIL utilisateur Cible 2 :Mot de passe ou crédentiel PKI PUP Cible2 non videà part s'il s'agit SSH de la config du système d'authentification SSL TELNET UpdateServic e VolP VPN WEB WIRELESS Application ApplicationPa yment GUI Multimedia Management SecurityTools 2 Host Firewall IDS Proxy Router Switch AUTHENTICATION CONFIG LOCKED SysAuth Account success UNLOCK Antivirus un failed AccotG roup APC AccountH ost error Audit AccountS ervice Chat Admin Database Anonymo us Domain Guest ESMP FTP IPSEC Verrouillage d'un compte LDAP UTILISATEUR Cible 1 : Service MAIL d'AUTHENTIFICATION du compte verrouillé Cible 2 : COMPTE PKI UTILISATEUR verrouillé PUP SSH SSL TELNET UpdateServic e VolP VPN WEB WIRELESS Application ApplicationPa yment GUI Multimedia Management SecurityTools Host Firewall IDS Proxy Router Switch AUTHENTICATION INFOONRMAT CONTROL I SysAuth Account valid Informations de contrôle Antivirus Acco un rouptG invalid concernant le processus d'authentification UPS AccountH ost notify Audit AccountS ervice Chat Admin Contrôle des propriétés du Database Anonymo Service d'authentification us Domain Guest ESMP Credentia I FTP Password IPSEC Certificat e Cible 2 : Propriétés vérifiées LDAP ConfFile MAIL Format PKI Method PUP Name SSH Paramete 3 r SSL Version TELNET Address UpdateServic e VolP VPN WEB WIRELESS Application ApplicationPa yment GUI Multimedia Management SecurityTools Host Firewall IDS Proxy Router Switch AUTHENTICATION INFORMAT ION THRESHO LD SysAuth Account low Antivirus AccoroupuntG expired UPS Acco osuntHt exceeded Audit AccountS ervice normal Chat Admin Contrôle des seuils concernant le processus d'authentification Database Anonymo us Domain Guest ESMP Certificat e FTP Credentia I Cible 1 : service d'authentification IPSEC Password Cible 2 : propriété sur laquelle le LDAP Address seuil porte MAIL Format PKI Method PUP Name SSH Paramete r SSL Version TELNET Time UpdateServic e VolP VPN WEB WIRELESS Application ApplicationF'a yment GUI Multimedia Management SecurityTools Host Firewall Cible 1 : service d'authentification IDS Cible 2 : compte sur lequel le Proxy seuil porte Router Switch AUTHENTICATION VULNERA BRUTEFO SysAuth Account detected 4 BILITY RCE Backdoor Antivirus AccountG roup BYPASS Audit AccountH ost CONCEAL Chat AccountS MENT ervice DOS Database Admin GAIN DNS Anonymo us HIJACKIN Domain Guest G INFORMAT ESMP Certificat IONGATHE e RING INFORMAT FINGER Credentia IONLEAK I INJECTION FTP Password OTHER IPSEC Address OVERFLO LDAP Format W PROTOCO MAIL Method L SPOOFING PKI Name STEAL PUP Paramete r VIOLATIO SSH Version N VIRUS SSL ConfFile TELNET UpdateServic e UPS VoIP VPN WEB WIRELESS Application ApplicationPa yment GUI Multimedia Management SecurityTools Host Firewall IDS Modem Proxy Router Switch Protocol ARP DHCP DNS Ethernet ICMP IP NFS Protocol RIP RPC Time UDP VLAN AUTHENT ICATION S BRUTEFORCE SysAuth Account detected SUSPICIO US DOS Antivirus AccountG roup HIJACKIN Audit AccountH ost G INFORMAT IONGATHE Chat AccountS ervice RING INFORMAT IONLEAK Database Admin INJECTION DNS Anonymo us OTHER Domain Guest OVERFLO ESMP Certificat W e VIO LA TIO FINGER Credentia N I FTP Password IPSEC Address LDAP Format MAIL Method PKI Name PUP Paramete r SSH Version SSL ConfFile TELNET UpdateServic e UPS VolP VPN WEB VVIRELESS Application ApplicationP a yment GUI Multimedia Management SecurityTools Host Firewall IDS Modem Proxy Router Switch Protocol ARP DHCP DNS Ethernet ICMP IP NFS Protocol RIP RPC Time UDP VLAN A UTHE NTICATION ATTACK K SysA uth Account detected BACRDOO BRUTEFO RCE Antivirus AccountG roup BYPASS Audit AccountH ost DOS Chat A AccountS ervice GAIN Database Admin INFORMAT DNS Anonymo IONGATHE us RING INFORMAT IONLEAK Domain Guest INJECTION ESMP Certificat 6 e OTHER FINGER Credentia I OVERFLO FTP Password W PROTOCO IPSEC Address L SPOOFING LDAP Format STEAL MAIL Method VIOLATIO PKI Name N PUP Paramete r SSH Version SSL ConfFile TELNET UpdateServic e UPS VolP VPN WEB WIRELESS Application ApplicationPa yment GUI Multimedia Management SecurityTools Host Firewall IDS Modem Proxy Router Switch Protocol ARP DHCP DNS Ethernet ICMP IP NFS Protocol RIP RPC Time UDP VLAN AUTHENTICATION MALWARE OTHER SysAuth detected VIRUS Antivirus UPS Audit Chat Database Domain FINGER ESMP FTP IPSEC LDAP MAIL PKI PUP SSH SSL TELNET UpdateServic e VolP 7 VPN WEB WIRELESS Application ApplicationPa yment GUI Multimedia Management SecurityTools Host Firewall IDS Proxy Router Switch Ces listes ne sont pas figées et sont actuellement en cours d'impinatation. 8 4.2 Cibles pour « RIGHTS » Groupes utilisateurs pour l'authentification AccouritGroup AdminGroup ServicE'Group Attributs et données de la gestion de droits Data Directory File Image Services de gestion des droits Propriétés particulières RIGHTS ACTIVITY READ Service Data success WRITE Chat Directory failed DELETE Database File error FTP URL MAIL Message OS Attach PKI PUP WEB Application Multimedia Protocol NFS Host Proxy Cluster RIGHTS ACTIVITY GAIN Service Account success Chat Admin failed Database Anonymous error FTP Guest MAIL AccountHost OS AccountService PUP AccountGroup _ PKI AdminGroup WEB ServiceGroup Application Multimedia Protocol NFS Host Proxy Cluster RIGHTS ACTIVITY GAIN Command Account success Admin failed Anonymous error Guest 9 AccountHost AccountService AccountGroup_ AdminGroup ServiceGrou Request WEB RIGHTS ACTIVITY RESTORE Service Data success BACKUP Chat Directory failed Database File error FTP URL MAIL Message OS Attach PUP PKI WEB Application Multimedia Protocol NFS Host Proxy Cluster RIGHTS ACTIVITY RESTORE Data Certificate success BACKUP Directory Credential failed File Password error URL Message attach RIGHTS CONFIG ADD AccountGroup Account success MODIFY AdminGroup Admin failed DELETE ServiceGroup Anonymous error Guest AccountHost AccountService RIGHTS CONFIG ADD Service ConfFile success MODIFY Chat Data failed DELETE Database Directory error FTP File MAIL License OS Log file Message PKI Parameter WEB Patch Application Pattern Multimedia Queue Protocol Registry NFS Sys Data Host Sys Directory Proxy Sys File Cluster RIGHTS CONFIG ADD Service Account success MODIFY Antivirus Admin failed DELETE UPS Anonymous error Audit Guest Chat AccountHost Database AccountService Domain AccountGroup FTP AdminGroup IPSEC ServiceGroup LDAP MAIL OS 0 PKI PUP SSH SSL TELNET Update_Service VolP VPN WEB WIRELESS Application GUI ApplicationPayment Multimedia Management SecurityTools Host Firewall IDS Proxy Router Switch RIGHTS CONFIG ADD Conf file ACL success MODIFY Data Address failed DELETE Directory Integrity error File Name License Method Logfile Message Parameter Path Parameter Version Patch Pattern Queue Registry Sys Data Sys_Directory Sys_File RIGHTS CONFIG ADD Conf file Certificate success MODIFY Data Credential failed DELETE Directory Password error File License Logfile Message Parameter Patch Pattern Queue Registry Sys Data Sys_Directory Sys File RIGHTS INFORMATION CONTROL Service Conffile valid Chat Data invalid Database Directory notify FTP File MAIL License OS Logfile Message PKI WEB Application Multimedia Protocol NFS Host 1 Proxy Cluster RIGHTS INFORMATION CONTROL Service Account valid Antivirus Admin invalid UPS Anonymous notify Audit Guest Chat AccountHost Database AccountService Domain AccountGroup FTP AdminGroup IPSEC ServiceGroup LDAP MAIL OS PKI PUP SSH SSL TELNET Update Service VolP VPN WEB WIRELESS Application ApplicationPayment GUI Multimedia Management SecurityTools Host Firewall IDS Proxy Router Switch RIGHTS INFORMATION CONTROL Conf file ACL valid Data Address invalid Directory lntegrity License notify File License Method Log_file Name Message Parameter Parameter Registry Patch Sys_Directory Pattern S s File Queue Version Registry Sys Data Sys_Directory Sys File RIGHTS INFORMATION CONTROL Conf file Certificate valid Data Credential invalid Directory Password notify File License Log_file Message Parameter Patch Pattern Queue Registry Sys Data Sys_Directory 2 Sys File RIGHTS INFORMATION CONTROL Certificate Integrity valid Credential Method invalid Password Version notify RIGHTS INFORMATION CONTROL AccountGroup Account valid AdminGroup Admin invalid ServiceGroup Anonymous notify Guest AccountHost AccountService RIGHTS INFORMATION THRESHOLD Service Data exceede d Chat Directory expired Database File low FTP URL normal MAIL Message OS Attach Conf_file PKI Parameter WEB Log_file Application Patch Multimedia Pattern Protocol Registry NFS Sys_File Host Sys Directory Proxy Sys Data Cluster license Queue RIGHTS INFORMATION THRESHOLD Service Account exceede d Antivirus Admin expired UPS Anonymous low Audit Guest normal Chat AccountHost Database AccountService Domain AccountGroup FTP AdminGroup -, IPSEC ServiceGrou LDAP license MAIL OS PKI PUP SSH -' SSL TELNET jpdateService VolP VPN WEB WIRELESS Application ApplicationParnent GUI Multimedia Management SecurityTools Host Firewall IDS Proxy Router Switch 3 RIGHTS INFORMATION THRESHOLD Data Integrity exceede d Directory Method expired File Version low URL normal Message Attach Conf_file Parameter Log_file Patch Pattern Registry Sys_File Sys_Directory Sys_Data license Queue RIGHTS INFORMATION THRESHOLD Data Certificate exceede d Directory Credential expired File Password low URL normal Message Attach Conf_file Parameter Log_file Patch Pattern Registry Sys_File Sys_Directory Sys_Data license Queue RIGHTS INFORMATION THRESHOLD Certificate Integrity exceede d Credential Method expired Password Version low normal RIGHTS INFORMATION THRESHOLD AccountGroup Account exceeded AdminGroup Admin expired ServiceGroup Anonymous low group Guest normal AccountHost AccountService RIGHTS VULNERABILITY BRUTEFORCE Service Data detected BYPASS Chat Directory DIRECTORYTR AVERSAL Database File DOS FTP URL EVASION MAIL Message GAIN OS Attach HIJACKING Conf_file INFORMATION GATHERING PKI Parameter INFORMATION LEAK WE B Log_file INJECTION Application Patch OVERFLOW Multimedia Pattern VIOLATION Protocol Registry OTHER NFS Sys_File 4 Host Sys_Directory Proxy Sys_Data Cluster license Queue SysAuth Antivirus detected UPS Audit Domain IPSEC LDAP PUP SSH SSL TELNET UpdateService VoIP VPN WIRELESS ApplicationPayment GUI Management SecurityTools Firewall IDS Router Switch RIGHTS VULNERABILITY BRUTEFORCE Data Integrity detected BYPASS Directory Method DIRECTORYTR AVERSAL File Version DOS URL EVASION Message GAIN Attach HIJACKING Conf file INFORMATION GATHERING Parameter INFORMATION LEAK Log_file INJECTION Patch OVERFLOW Pattern VIOLATION Registry Sys_File OTHER Sys_Directory , Sys_Data license Queue RIGHTS VULNERABILITY BRUTEFORCE Data Certificate detected BYPASS Directory Credential DIRECTORYTR AVERSAL File Password DOS URL EVASION Message Attach GAIN HIJACKING Conf file INFORMATION GATHERING Parameter INFORMATION LEAK Log_file INJECTION Patch OVERFLOW Pattern VIOLATION Registry Sys_File OTHER Sys_Directory Sys_Data license Queue RIGHTS VULNERABILITY BRUTEFORCE Certificate Integrity detected BYPASS Credential Method DIRECTORYTR AVERSAL Password Version DOS EVASION GAIN HIJACKING INFORMATION GATHERING INFORMATION LEAK INJECTION OVERFLOW VIOLATION OTHER RIGHTS VULNERABILITY BRUTEFORCE AccountGroup Account detected BYPASS AdminGroup Admin DIRECTORYTR AVERSAL ServiceGroup Anonymous DOS Guest EVASION AccountHost GAIN AccountService HIJACKING INFORMATION GATHERING INFORMATION LEAK INJECTION OVERFLOW VIOLATION OTHER RIGHTS SUSPICIOUS GAIN Service Data detected VIOLATION Chat Directory OTHER Database File FTP URL MAIL Message OS Attach Conf_file PKI Parameter WEB Log file Application Patch Multimedia Pattern Protocol Registry NFS Sys_File Sys_Directory Host F,i' Sys_Data license -oxy Cluster Queue RIGHTS SUSPICIOUS GAIN SysAuth Account detected VIOLATION Antivirus Admin OTHER UPS Anonymous Guest Audit Chat AccountHost Database AccountService Domain AccountGroup_ FTP AdminGroup ServiceGroup_ IPSEC LDAP MAIL OS 6 PKI PUP SSH SSL TELNET UpdateService VolP VPN WEB WIRELESS Application ApplicationPayment GUI Multimedia Management SecurityTools Host Firewall IDS Proxy Router Switch RIGHTS SUSPICIOUS GAIN Data Integrity detected VIOLATION Directory Method OTHER File Version URL Message Attach Conf_file Parameter Log_file Patch Pattern Registry Sys_File Sys_Directory Sys_Data license Queue RIGHTS SUSPICIOUS GAIN Data Certificate detected VIOLATION Directory Credential OTHER File Password URL Message Attach Conf_file Parameter Logfile Patch Pattern Registry Sys_File Sys Directory Sys_Data license Queue RIGHTS SUSPICIOUS GAIN Certificate Integrity detected VIOLATION Credential Method OTHER Password Version RIGHTS SUSPICIOUS GAIN AccountGroup Account detected VIOLATION AdminGroup Admin OTHER ServiceGroup Anonymous Guest AccountHost AccountService 7 RIGHTS ATTACK BYPASS Service Data detected BRUTEFORCE Chat Directory DIRECTORYTR AVERSAL Database File DOS FTP URL GAIN MAIL Message INFORMATION GATHERING OS Attach INFORMATION LEAK - Conf file INJECTION PKI Parameter OTHER WEB Log_file OVERFLOW Application Patch VIOLATION Multimedia Pattern Protocol Registry NFS Sys_File Host Sys_Directory Proxy Sys_Data Cluster license Queue RIGHTS ATTACK BYPASS Sys_Auth Account detected BRUTEFORCE Antivirus Admin DIRECTORYTR AVERSAL UPS Anonymous DOS Audit Guest GAIN Chat AccountHost INFORMATION GATHERING Database AccountService INFORMATION LEAK Domain AccountGroup INJECTION FTP AdminGroup OTHER IPSEC ServiceGroup OVERFLOW LDAP VIOLATION MAIL OS PKI PUP SSH SSL TELNET Update_Service VolP VPN WEB WIRELESS Application ApplicationPa rry_nt GUI Multimedia Management SecurityTools Host Firewall IDS Proxy Router Switch RIGHTS ATTACK BYPASS Data Integrity detected BRUTEFORCE Directory Method DIRECTORYTR AVERSAL File Version DOS URL GAIN Message INFORMATION GATHERING Attach INFORMATION Conf file 8 LEAK INJECTION Parameter OTHER Log_file OVERFLOW Patch VIOLATION Pattern Registry Sys_File Sys_Directory Sys_Data license Queue RIGHTS ATTACK BYPASS Data Certificate detected BRUTEFORCE Directory Credential DIRECTORYTR. AVERSAL File Password DOS URL GAIN Message INFORMATION GATHERING Attach INFORMATION LEAK Conf file INJECTION Parameter OTHER Log_file OVERFLOW Patch VIOLATION Pattern Registry Sys_File Sys_Directory Sys_Data license Queue RIGHTS ATTACK BYPASS Certificate Integrity detected BRUTEFORCE Credential Method DIRECTORYTR AVERSAL Password Version DOS GAIN INFORMATION GATHERING INFORMATION LEAK INJECTION OTHER OVERFLOW VIOLATION RIGHTS ATTACK BYPASS AccountGrou Account detected BRUTEFORCE AdminGroup Admin DIRECTORYTR AVERSAL ServiceGroup Anonymous DOS Guest GAIN AccountHost INFORMATION GATHERING AccountService INFORMATION LEAK INJECTION OTHER OVERFLOW VIOLATION Ces listes ne sont pas figées et sont actuellement en cours d'impinatation. 9 4.3 Cibles pour SYSTEM Equipements Host Cluster Firewall IDS Modem PrinterDevice Proxy 0 Objets réseau Router Switch Traffic VPN 1 Protocoles Chat Database Ethernet MAIL Management PinterProtocol Protoccl Time VolP WEB Wireless ARP DHCP DNS FTP ICMP IP IPSEC LDAP NFS PUP P2P RIP RPC SSH SSL TCPIP TELNET UDP VLAN VPN 2 Services Antivirus APC Audit Chat Database DHCP DNS Domain EAS FTP IPSEC LDAP MAIL Management Multimedia NFS OS P2 P PinterProtocol PKI PUP P2 P RPC SecurityTools Service SSH SSL SysAuth TCPIP TELN ET Time Tunnel VolP 3 VPN WEB Wireless 4 Services réseau spécifiques Appllications Générique Application Audit Management Outils de sécurité AntivirLs Applications de paiement électronique Applications utilisateurs Applications multimédia 6 Attributs et données système Attributs des données Reply Request URL Message Attach Données Conf file Log_file Patch Pattern Registre Sys_File Sys_Directory Sys_Data Licence Queue Réseau Table Trap Port Packet Traffic 7 Executables Command Process 8 References [1] Edward G. Amoroso. Fundamentals of computer security technology. Prentice-Hall, Inc, Upper Saddle River, NJ, USA, 1994. [2] M. Bishop. How attackers break programs, and how to write programs more securely. SANS 2002, Baltimore,MD, May 2002. [3] M Brand. Intending and acting. Cambridge, MA: MIT Press, 1984. [4] M. E Bratman. Intention, plans, and practical reason. Cambridge, MA: Cambridge University Press, 1987. [5] W. R. Cheswick and S. M. Bellovin. Firewalls and Internet SecurityRepelling the Wily Hacker. Addison-Wesley, 1994. [6] Frederick B. Cohen. Protection and security on the information superhighway. John Wiley & Sons, Inc., New York, NY, USA, 1995. [7] Frederick B. Cohen. Information system attacks: A preliminary classification scheme. Computers and Security, 16, No. 1:29-46, 1997. [8] F. Cuppens. Managing alerts in a multi-intrusion detection environment. page 22,2001. [9] D. Curry and H. Debar. Intrusion detection message exchange format. [10] John Perry David Israel and Syun Tutiya. Executions, motivations and accomplishments. [11] Davidson. Actions, reasons, and causes. Journal of Philosophy, pages 685700 (Reprinted in Davidson 1980, pp. 3-19.), 1963. [12] D Davidson. Freedom to act. Honderich (ed.), Essays on Freedom of Action (London: Routledge & Kegan Paul, 1973, reprinted with corrections, 1978) pp. 137-156., 1973. [13] Steven T. Eckmann, Giovanni Vigna, and Richard A. Kemmerer. STATL: an attack language for state-based intrusion detection. J. Comput. Secur, 10:71-103,2002. [14]J. Howard and T. Longstaff. A common language for computer security incidents. Sand98-8667, Sandia International Laboratories, 1998. [15] John D. Howard. An Analysis of Security Incidents on the Internet normalement phd dissertation-. PhD thesis, Carnegie Mellon University, Pittsburgh, Pennsylvania 15213 USA, April 1997. [16] Ming-Yuh Huang, Robert J. Jasper, and Thomas M. Wicks. A large scale distributed intrusion detection frarnework based on attack strategy analysis. Computer Networks (Amsterdam, Netherlands: 1999, 31(23-24):2465-2475, 1999. [17] David Icove, Karl Seger, and William VonStorch. Computer Crime: A Crimefighter's Handbook. Inc., Sebastopol, CA, 1995. [18] Ivan Krsul. Software Vulnerability Analysis. PhD thesis, Purdue University, US, May 1998. [19] UIf Lindqvist and Erland Jonsson. How to systematically classify computer security intrusions. In proceeding of the IEEE Symposium on Security and Privacy, pages 154-163,1997. [20] A.R Mele. Springs of action, understanding intentional behavior. Oxford University Press, 1992. 9 [21] Frank van Harmelen James Hendler lan Horrocks Deborah L. McGuinness Peter F. Patel-Schneider Mike Dean, Dan Connolly and Lynn Andrea Stein. OWL web ontology langage overview, W3C recommendation 10 february 2004. [22] B. Morin. Corrélation d'alertes issues d'outils de détection d'intrusions avec prise en compte d'informations sur le système surveillé. PhD thesis, INSA de Rennes, Février 2004. [23] Peter G. Neumann. Computer-Related Risks. Addison-Wesley, October 1994. [24] Peter G Neumann and Donn B Parker. A summary of computer misuse techniques. In Proceedings of the 12th National Computer Security Conference, pages 396-407, Baltimore, Maryland, October 1989. [25] P. A. Porras and P. G. Neumann. EMERALD : Event Monitoring Enabling Responses to Anomalous Live Disturbances. In Proc. 20th NIST-NCSC National Information Systems Security Conference, pages 353-365,1997. [26] Dordrecht: D. Reide. Intending. in y. yovel (ed.), philosophy of history and action. pp. 41-60. (reprinted in davidson 1980, pp. 83-102.). [27] Deborah Russell and Sr. G. T. Gangemi. Computer security basics. O'Reilly & Associates, Inc., Sebastopol, CA, USA, 1991. [28] R. Crawford M. Dilger J. Frank J. Hoagland K Levitt C. Wee R. Yip S. Stani ford Chen, S. Cheung and D. Zerkle. GrIDS : A graph based intrusion detection system for large networks. In Proceedings of the 19th National Information Systems Security Conference, 1996. [29]J Searle. lntentionality: An Essay in the Philosophy of Mind. Cambridge University PressNew York, 1983. [30] Steven R. Snapp, James Brentano, Gihan V. Dias, Terrance L. Goan, L. Todd Heberlein, Che lin Ho, Karl N. Levitt, Biswanath Mukherjee, Stephen E. Smaha, Tim Grance, Daniel M. Teal, and Doug Mansur. DIDS (distributed intrusion detection system) motivation, architecture, and an early prototype. In Proceedings of the 14th National Computer Security Conference, pages 167-176, Washington, DC, 1991. [31] William Stallings. Network and internetwork security: principles and practice. Prentice-Hall, Inc, Upper Saddle River, NJ, USA, 1995. [32] Andrew J. Stewart. Distributed metastasis: A computer network penetration methodology. [33] Jeffrey L Undercoffer, Anupam Joshi, and John Pinkston. Modeling computer attacks an ontology for intrusion detections. In LNCS-2516, editor, The Sixth International Symposium on Recent Advances in Intrusion Detection. Springer, September 2003. [34] Alfonso Valdes and Keith Skinner. Probabilistic alert correlation. In Proceedings of Recent Advances in Intrusion Detection 2001, LNCS 2212, pages 54-68, ISBN 3-540-427202,2001. REVENDICATIONS1. Procédé de modélisation d'une activité dans un système d'information caractérisé en ce qu'il met en oeuvre une ontologie basée sur quatre classes que sont l'intention, le mouvement et la cible et le gain.