Agrégation d’alarmes faiblement structurées

Présentation au sujet: "Agrégation d’alarmes faiblement structurées"— Transcription de la présentation:

1 Agrégation d’alarmes faiblement structurées
Alexandre Vautier, Marie Odile Cordier, Mireille Ducassé et René Quiniou Ne rien dire de particulier Dire que l’explication du titre va venir dans la suite

2 Normalisation des alarmes (1/6) Contexte
clients alarmes Concentrateur VPN : Composant réseau chargé de gérer des connexions VPN Journal d’alarmes connexions Date Type Autres champs (client; message) 05/09/ :11:02.750 IKE/24 ; « Received local Proxy Host data in ID Payload: Address , Protocol 17, Port 0 » 05/09/ :12:28.500 IKE/41 ;IKE Initiator: Rekeying Phase 2, Intf 2, IKE Peer local Proxy Address , remote Proxy Address , SA (WindowsServer1) …. plus d’un million d’alarmes

3 Problématique Processus d’extraction des connaissances
Journal d’alarmes Représentation Interactivité incrémentale Aider l’opérateur à exprimer ses connaissances Extraire un résumé du journal Opérateur Processus d’extraction des connaissances

4 Plan Introduction Un exemple concret Les 3 étapes du processus
Normalisation Agrégation Généralisation Perspectives Conclusion L’exemple concret porte sur les 3 étapes détaillées ensuite et sur l’étape finale en perspective

5 Modèles de normalisation
Date Type Attributs A [paul, server1] 2 C [paul, 0x10] 9 [pierre, server1] 11 [pierre,0x11] 45 B [0x11, 44] 46 [0x11, 112] 47 D [server1, 0x11, pierre] 68 [0x10, 54] 70 [0x10, 40] 102 E [0x10, 486A14FE] Modèles de normalisation

6 Agrégation paramètres A [paul, server1] 2 C [paul, 0x10] Date Type
A [paul, server1] 2 C [paul, 0x10] Date Type Attributs A [paul, server1] 2 C [paul, 0x10] 9 [pierre, server1] 11 [pierre,0x11] 45 B [0x11, 40] 46 [0x11, 112] 47 D [server1, 0x11, pierre] 68 [0x10, 54] 70 [0x10, 40] 102 E [0x10, 486A14FE] 9 A [pierre, server1] 11 C [pierre,0x11] 45 B [0x11, 40] 46 [0x11, 112] 47 D [server1, 0x11, pierre] paramètres 68 B [0x10, 54] 70 [0x10, 40] 102 E [0x10, 486A14FE]

7 Généralisation Modèles de transaction Type Attributs t1: A [m,n] C
Type Attributs t1: A [m,n] C [m,o] t2: B [p,q] [p,r] D [s,p,t] t3: [u,v] [u,w] t4: E [x,y] A [paul, server1] 2 C [paul, 0x10] 9 A [pierre, server1] 11 C [pierre,0x11] 45 B [0x11, 40] 46 [0x11, 112] 47 D [server1, 0x11, pierre] m 2 *; n=server1; o=0x1?; … ; y=… t1 [m=paul, n=server1, o=0x10] 9 [m=pierre, n=server1, o=0x11] 45 t2 [p=0x11, q=40, r=112, s=server1, t=pierre] 68 t3 [u=0x10, v=54, w=40] 102 t4 [x=0x10, y=486A14FE] 68 B [0x10, 54] 70 [0x10, 40] 102 E [0x10, 486A14FE]

8 Construction des connexions perspectives
t1 [m=paul, n=server1, o=0x10] 9 [m=pierre, n=server1, o=0x11] 45 t2 [p=0x11, q=40ms, r=112, s=server1, t=pierre] 68 t3 [u=0x10, v=54, w=40] 102 t4 [x=0x10, y=486A14FE] Connexion « paul » Connexion « pierre » t1 [m=paul, n=server1, o=0x10] 9 t1 [m=pierre, n=server1, o=0x11] 45 t2 [p=0x11, q=54, r=40, s=server1, t=pierre] 68 t3 [u=0x10, v=40, w=112] 102 t4 [x=0x10, y=486A14FE] …construction de modèles de connexions

9 Normalisation des alarmes
But : uniformiser la représentation des alarmes Problème : message faiblement structuré Solution : extraction d’une liste d’attributs à partir des messages Contrainte : A un type d’alarme correspond une liste de types d’attribut.

10 Exemple de normalisation d’alarmes
Par signature d’attribut Par signature d’alarme Expressions régulières : Message : Message normalisé : Nombres décimaux Nombres hexadécimaux No answer from handle number 0x11 after 40ms [0x11, 40] Expression régulière : Message : Message normalisé : Attribution of handle (Nombre hexadécimal) to user (chaîne de caractères) Attribution of handle 0x11 to user pierre [0x11, pierre]

11 Normalisation des alarmes (3/6) Méthode
Journal Journal normalisé Signatures d’attibut : (nombres - base 10 ou 16) Signatures d’alarme :

12 Normalisation des alarmes (4/6) Signature d’attribut
Définition : expression régulière représentant la forme d’un attribut à extraire dans le message d’une alarme. Moyen d’introduire des connaissances approximatives sur le journal par l’opérateur Exemples : Adresse IP: « 25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3} 25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9] » Nom d’utilisateur : « User\s\[(\w*)\] »

13 Normalisation des alarmes (5/6) Signature d’alarmes
Sous la forme d’expressions régulières Propre à un type d’alarme Résultat et paramètre de la normalisation. Synthèse et spécification de la façon dont les attributs sont extraits pour un type d’alarme donné. Moyen d’exprimer les connaissances précises de l’opérateur Utile pour des messages très variables

14 Normalisation des alarmes (6/6) Étude de cas -> plus graphique !!
d’alarmes du journal du concentrateur VPN (1 mois de fonctionnement) 4 signatures d’attributs présents à la première extraction automatique 4 extractions automatiques Ajout de 3 signatures d’attribut 37 signatures générées ont du être modifiées et utilisées pour l’extraction

15 Agrégation des alarmes (1/4)
Propriétés du journal : des transactions identiques de types d’alarme apparaissent dans le journal. ) propriété permettant de synthétiser l’information. Problème : déterminer quelles transactions sont à extraire. Les alarmes d’une transaction partagent des valeurs d’attribut identique. Solution : corréler les valeurs des attributs pour agréger des alarmes proches dans le temps en transactions primitives puis analyser ces transactions.

16 Agrégation des alarmes (2/4) Corrélation relationnelle
Deux alarmes sont corrélées si : Elles partagent au moins na attributs identiques. Et si le délai qui les sépare est inférieur à maxGap. Une alarme a est agrégée à une transaction T si il existe une alarme b de T corrélée à l’alarme a. Les paramètres maxGap et na sont donnés a priori par l’opérateur « L’agrégation donne un aperçu rapide. » Pour des paramètres donnés et un journal donné, Il existe une unique façon d’agréger les alarmes

17 Agrégation des alarmes (4/4) Influence du paramètre maxGap
na = 1 maxGap Date Type Attributs A [paul, server1] 2 C [paul, 0x10] 9 [pierre, server1] 11 [pierre,0x11] 45 B [0x11, 40] 46 [0x11, 112] 47 D [server1, 0x11, pierre] 68 [0x10, 54] 70 [0x10, 40] 102 E [0x10, 486A14FE] Empêcher la corrélation entre attributs non pertinents

18 Organisation des transactions (1/6)
Généralisation des transactions primitives sous la forme de modèles de transaction dans un espace muni d’une relation d’ordre. But : organiser l’information afin de mieux la compresser relativement aux connaissances de l’opérateur Moyen : Visualisation des transactions et modifications par l’opérateur Méthodes automatiques (règles d’associations)

19 Organisation des transactions (2/6) Modèle de transaction
Un modèle d’alarme : Alarme sans date dont les attributs sont remplacés par des variables. Le type reste inchangé. Une variable possède un type et son domaine est contraint. Exemple : Alarme : 47 D [server1, 0x11, pierre] Modèle d’alarme : D [a,b,c] Variables : a[s] 2 *, b[i] 2 0x00..0xFF, c[s] 2 * Un modèle de transaction : Séquence de modèles d’alarme associés à leurs variables. Un modèle de transaction (resp. alarme) couvre des transactions (resp. alarmes) appelées ses instances.

20 Organisation des transactions (4/) Représentation
B [u,v] [u,w] u[i]=0x1?, v[i]=*, w[i]=* D [x,y,z] x[s]=*, y[i]=0x10, z[s]=* t4 t3 B [p,q] [p,r] D [s,p,t] p[i]=*, q[i]=*, r[i]=*, s[s]=*, t[s]=* t2

21 Organisation des transactions (4/6) Relation d’ordre partiel
Relation sur les modèles d’alarme : Une alarme Ag est plus général qu’une alarme As ssi Leurs types sont identiques les domaines des variables de As sont plus contraints ou égaux à ceux de Ag Relation sur les modèles de transaction Une transaction Tg est plus générale qu’une transaction Ts « intuition : toutes les alarmes de Tg sont dans Ts » ssi Il existe un appariement entre toutes les alarmes de Tg et des alarmes de Ts respectant le relation d’ordre sur les alarmes.

22 Organisation des transactions (5/6) Étude de cas-1
Effectuée sur les 5000 premières alarmes du journal Maxgap = 10s et na = 1 Construction de 628 transactions primitives généralisées par 81 modèles de transactions.

23 Organisation des transactions (6/6) Étude de cas-2
Un modèle de transaction de 8 alarmes couvre 41% des alarmes du journal 80 % des modèles générés n’ont qu’une seule instance dans le journal

24 Perspectives modifications des transactions
par fusion/découpage par addition de corrélations statistiques règles d’associations entre transactions manuelles puis automatiques (opérateur) analyse des variables (en post-traitement)

25 Perspective amélioration de la normalisation
Inférence grammaticale pour extraire les attributs Pas super important car la tache n’est pas lourde actuellement

26 Perspectives (1/2) Caractérisation des attributs
Des transactions primitives sont construites à partir d’attributs inintéressants (date, serveur…) Classification des attributs en Identifiant de connexion/transaction Paramètres Classification manuelle puis automatique (technique d’apprentissage)

27 Agrégation d’alarmes faiblement structurées Conclusion
Données en nombre et faiblement structurées. Techniques simples mises en œuvres sur des données réelles. Toujours assisté, l’opérateur contrôle la chaîne de processus afin qu’elle lui fournisse une représentation du journal. « Acquisition de connaissances par l’expert tout au long du processus d’extraction  manipulation seule des résultats »

28 Agrégation d’alarmes faiblement structurées Alexandre Vautier, Marie Odile Cordier, Mireille Ducassé et René Quiniou Processus interactif d’assistance à l’expression et à l’extraction des connaissances MERCI !

29 Soient deux modèles d’alarmes Ag et As. Ag est plus général que As , Ag.type == As.type et 8 vg 2 Ag, 9 vs 2 As, dom(vs) 2 dom(vg)

30 Normalisation des alarmes (2/7) Problématique
Extraction assistée (par l’opérateur) des attributs Date Type Champs « texte » Date Type Liste d’attributs […;…;…] Caractéristique essentielle : pour un type d’alarme donné, seuls les attributs changent dans le message… normalement… - Quels attributs ? - Quelles sont mes connaissances sur la structure des alarmes ?

31 Problématique Un journal d’alarmes processus « Résumé »
Caractéristiques : alarmes datées, typées faiblement structurées, en grand nombre et implicitement liées à un contexte Caractéristiques : compréhensible par l’opérateur (taille et sémantique) perd le moins possible d’informations par rapport au journal : sous la forme de séquences de modèle d’alarme basé sur des corrélations relationnelles entre alarmes Résultats intermédiaires Connaissances Opérateur

32 Problématique Les données : un journal composées d’alarmes qui sont :
datées, typées et faiblement structurées (essentiellement du texte) en grand nombre ( > ) Un opérateur avec peu de connaissances sur le journal et sans question précise Quelles connaissances extraire du journal ? Y’a-t-il eu des attaques (dans un contexte réseau) ?

33 Normalisation des alarmes (3/6) Méthode
Signatures d’attribut Signatures d’alarme Journal Extraction automatique Signatures d’alarmes Journal normalisé