Agrégation d’alarmes faiblement structurées

Alexandre Vautier, Marie Odile Cordier,Mireille Ducassé et René Quiniou

Normalisation des alarmes (1/6)

Contexte

Journal d’alarmes

clients

Concentrateur VPN :Composant réseau chargé de

gérer des connexions VPNconnexions

Date Type Autres champs (client; message)

05/09/200423:11:02.750

IKE/24 80.13.14.15; « Received local Proxy Host data in ID Payload: Address 85.75.65.55, Protocol 17, Port 0 »

05/09/200423:12:28.500

IKE/41 ;IKE Initiator: Rekeying Phase 2, Intf 2, IKE Peer 81.71.61.51 local Proxy Address 85.75.65.55, remote Proxy Address 81.71.61.51, SA (WindowsServer1)

alarmes

…. plus d’un million d’alarmes

Problématique

ReprésentationJournal d’alarmes

Interactivité incrémentale

Opérateur

Aider l’opérateur à exprimerses connaissancesExtraire un résumé du journal

Processus d’extraction des connaissances

Plan

► Introduction► Un exemple concret

► Les 3 étapes du processus► Normalisation► Agrégation► Généralisation

► Perspectives► Conclusion

Normalisation

Date Type Attributs

0 A [paul, server1]

2 C [paul, 0x10]

9 A [pierre, server1]

11 C [pierre,0x11]

45 B [0x11, 44]

46 B [0x11, 112]

47 D[server1, 0x11, pierre]

68 B [0x10, 54]

70 B [0x10, 40]

102 E [0x10, 486A14FE]

Modèles de normalisation

Agrégation0 A [paul, server1]

2 C [paul, 0x10]

9 A [pierre, server1]

11 C [pierre,0x11]

45 B [0x11, 40]

46 B [0x11, 112]

47 D[server1, 0x11, pierre]

102 E [0x10, 486A14FE]

Date Type Attributs

0 A [paul, server1]

2 C [paul, 0x10]

9 A [pierre, server1]

11 C [pierre,0x11]

45 B [0x11, 40]

46 B [0x11, 112]

47 D[server1, 0x11, pierre]

68 B [0x10, 54]

70 B [0x10, 40]

102 E [0x10, 486A14FE]

68 B [0x10, 54]

70 B [0x10, 40]

paramètres

Généralisation

0 A [paul, server1]

2 C [paul, 0x10]

9 A [pierre, server1]

11 C [pierre,0x11]

45 B [0x11, 40]

46 B [0x11, 112]

47 D[server1, 0x11, pierre]

102 E [0x10, 486A14FE]

68 B [0x10, 54]

70 B [0x10, 40]

0 t1 [m=paul, n=server1, o=0x10]

9 t1 [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]

  Type Attributs

t1: A [m,n]

  C [m,o]

t2: B [p,q]

  B [p,r]

  D [s,p,t]

t3: B [u,v]

  B [u,w]

t4: E [x,y]

Modèles de transaction

m 2 *; n=server1; o=0x1?; … ; y=…

Construction des connexionsperspectives

0 t1 [m=paul, n=server1, o=0x10]

9 t1 [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]

9 t1 [m=pierre, n=server1, o=0x11]

0 t1 [m=paul, n=server1, o=0x10]

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]

Connexion « paul » Connexion « pierre »

…construction de modèles de connexions

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.

Exemple de normalisation d’alarmes

► Par signature d’attribut

► Par signature d’alarme

No answer from handle number 0x11 after 40ms

Nombres hexadécimaux

Nombres décimaux

[0x11, 40]

Expressions régulières :

Message :

Message normalisé :

Attribution of handle (Nombre hexadécimal) to user (chaîne de caractères)

Attribution of handle 0x11 to user pierre

Expression régulière :

Message :

Message normalisé : [0x11, pierre]

Normalisation des alarmes (3/6)

Méthode

Journal Journal normalisé

Signatures d’attibut :(nombres - base 10 ou 16)

Signatures d’alarme :

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*)\] »

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

Normalisation des alarmes (6/6)

Étude de cas -> plus graphique !!► 1.262.117 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

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.

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

Agrégation des alarmes (4/4)

Influence du paramètre maxGap

Date Type Attributs

0 A [paul, server1]

2 C [paul, 0x10]

9 A [pierre, server1]

11 C [pierre,0x11]

45 B [0x11, 40]

46 B [0x11, 112]

47 D [server1, 0x11, pierre]

68 B [0x10, 54]

70 B [0x10, 40]

102 E [0x10, 486A14FE]

2 9 23 32 34

maxGapna = 1

Empêcher la corrélation entre attributs non pertinents

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)

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.

Organisation des transactions (4/)

Représentation

B [p,q]

B [p,r]

D [s,p,t]

 

p[i]=*, q[i]=*, r[i]=*,

s[s]=*, t[s]=*

B [u,v]

B [u,w]

 u[i]=0x1?, v[i]=*, w[i]=*

D [x,y,z]

  x[s]=*, y[i]=0x10, z[s]=*

t2

t3 t4

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.

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.

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

Perspectivesmodifications des transactions

►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)

Perspectiveamélioration de la normalisation

►Inférence grammaticale pour extraire les attributs► Pas super important car la tache n’est pas

lourde actuellement

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)

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 »

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 !

alexandre.vautier@irisa.fr

►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)

Normalisation des alarmes (2/7)

Problématique

Extraction assistée (par l’opérateur) des attributs

Date Type Liste d’attributs

[…;…;…]

Date Type Champs

« texte »

- Quels attributs ?- Quelles sont mes connaissances sur la structure des alarmes ?

Caractéristique essentielle : pour un type d’alarme donné, seuls les attributs changent dans le message… normalement…

Problématique

« Résumé »Un journal d’alarmes processus

Opérateur

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

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 ( > 1.000.000 )

► 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) ?

Normalisation des alarmes (3/6)

Méthode

Signatures d’attributSignatures d’alarme

Journal

Journal normalisé

Signatures d’alarmes

Extraction automatique