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