En général, il y a plusieurs étapes dans l’exploitation des logs au sein d’une entreprise :

• La première étape est de se rendre compte qu’il y a des logs et que l’on pourrait en faire quelque chose.
• La deuxième étape est l’archivage de ces logs souvent pour des raisons légales.
• La troisième étape consiste à concentrer tous les logs de l’entreprise en un point unique, d’une part afin de mutualiser les moyens mis en œuvre pour l’archivage, et d’autre part pour pouvoir mettre en place un processus d’exploitation plus global.

A partir de ce point, la démarche d’exploitation peut suivre deux voies différentes, complémentaires mais pas forcément exclusives l’une de l’autre.

• Le processus de supervision en temps réel. Ce processus va reposer sur la mise en place d’un SOC (Security Operation Center) et le déploiement d’un logiciel qui permette l’agrégation et la corrélation de ces logs générant des alarmes de supervision en temps réel.
• Le processus de visualisation des logs. Ce processus peut être une analyse en temps réel ou a posteriori (suite à un incident déclaré par exemple).

La mise en place du processus de visualisation est une démarche plus ou moins itérative en fonction du degré de connaissance que l’on acquiert sur les logs traités.

La corrélation de logs

Dans les grandes lignes, la corrélation de logs consiste tout d’abord à agréger les logs similaires (même source, même message, même instant temporel) et ensuite à l’aide de scénarios définis par l’exploitant de générer de nouveaux meta événements possédant plus d’information qualitative.

Exemple de scénario simple : Si le log est à destination du port 21 et si le log suivant est à destination du port 22 et si le log suivant est à destination du port 23 et que ces 3 logs ont lieu en moins de 1 minute alors un balayage de ports est probablement en cours à destination de cette machine.

La corrélation des logs est une activité puissante, aux intérêts indéniables. Il faut être conscient cependant qu'elle a aussi des limites.

• Le problème de la corrélation de logs est lié aux différents scénarios. En effet, il faut écrire ces différents scénarios et un scénario qui n’est pas imaginé ne sera pas écrit et donc la tentative (ou réussite) d’intrusion ne sera pas détectée.
• De plus, il est parfois impossible de corréler un événement avec un log précédent par manque de contexte. Par exemple, il est parfois impossible en cas de session SSH simultanée sur une machine, de lier un événement SUDO à une session plutôt qu’à une autre.
• Une autre difficulté de la corrélation est que c’est un processus qui demande extrêmement de mémoire et de puissance CPU lors de l’analyse.

• Les phénomènes répétitifs ou les phénomènes qui produisent un schéma régulier parmi un brouillard (nuage) de logs qui semble aléatoire.
• Les phénomènes aléatoires parmi un schéma de logs prévu et attendu qui devrait être régulier ou répétitif.

Pour que les logs soient visualisables, il faut qu’ils possèdent certaines caractéristiques ;

• Ils doivent être nombreux. En effet, il est inutile de visualiser seulement quelques lignes de logs, une simple analyse du fichier suffit.
• Ils doivent contenir des informations numériques afin de positionner les valeurs sur un axe de visualisation. Ces informations numériques peuvent être natives (des nombres, des numéros de port) ou facilement reconstruites (des adresses IP, des dates).
• Ils doivent contenir plusieurs dimensions numériques (au moins 2).

Les contraintes liées à la visualisation des logs sont les suivantes :

• L’opérateur doit savoir ce qu’il veut représenter, comment il veut le représenter et ce que cela va donner comme image a priori.
• Si le résultat affiché n’est pas le résultat escompté, le travail d’interprétation du résultat peut être complexe.

• visiter le site www.secviz.org (site dédié à la visualisation des logs) et sa galerie.
• Explorer le "live-CD" DAVIX qui propose un ensemble d'outils permettant de visualiser des logs.