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

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/2004 23: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/2004 23: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) …. plus d’un million d’alarmes

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

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

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

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]

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]

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

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 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]

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 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] 2 9 23 32 34 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 [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

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

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)

Perspective amé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 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 ?

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

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’attribut Signatures d’alarme Journal Extraction automatique Signatures d’alarmes Journal normalisé