Le processus d’analyse de log à l’ère du Machine Learning

Comment traiter ses données pour pouvoir les analyser avec des algorithmes de Machine Learning ?

Avec la généralisation des pratiques associées au data analytics, tout le monde veut faire du Machine Learning ou de l’IA. Bien qu’il existe de nombreux outils pour appliquer des algorithmes de Machine Learning facilement à un dataset, il n’en est pas devenu beaucoup plus facile pour les administrateurs systèmes et réseaux ainsi que les analystes en SOC d’appliquer des méthodes d’analyse statistiques et de Machine Learning au workflow habituel d’analyse de log. Voyons quels sont les problèmes et abordons ensemble quelques pistes de résolution !

Le processus de traitement classique

Historiquement, le processus de traitement des logs était (et est toujours majoritairement ) basiquement le suivant :

1. Génération : La première étape consiste à produire des Logs qui quadrillent l’infrastructure.
2. Centralisation : Il faut ensuite envoyer et agréger tous les logs sur une infrastructure centrale.
3. Parsing / Enrichissement / Normalisation : Il est ensuite essentiel de traiter la donnée pour pouvoir la visualiser et l’analyser efficacement.
4. Stockage / Indexation : Pour pouvoir analyser les logs, ceux ci-doivent être disponibles avec une faible latence et stockés dans une Base de données permettant la recherche.
5. Visualisation & Analyse : On représente ensuite la donnée de manière à pouvoir l’explorer et la comprendre.
6. Détection & Alerting : On utilise la phase précédente pour déduire des règles de détection de dysfonctionnement ou d’indicateur de compromission. Ces règles génèrent des alertes actionnables.

Il existe plusieurs ensembles d’outils open-source permettant de réaliser ces différentes étapes. Certains forment un “stack” : un ensemble d’outils cohérents entre eux qui permettent de gérer une partie importante de la chaîne de traitement. Par exemple le stack Elastic permet de générer des logs grâce au Beats, de centraliser, parser, enrichir, normaliser avec Logstash, puis de stocker et indexer sur Elasticsearch, et finalement, on peut visualiser la donnée sur Kibana. D’autres outils indépendants viennent se greffer à ces Stacks, par exemple Elastalert vient remplacer la fonction d’alerting payante du stack Elastic.

Globalement, on peut considérer que ce processus est bien instrumenté et commence à être maîtrisé dans de nombreuses entreprises. Il reste encore du travail sur les 2 dernières étapes, l’analyse et l’alerting. Encore aujourd’hui, de nombreuses sociétés n’arrivent pas à potentialiser sur leur Data Lake faute de moyen ou de compétences.

Le paradigme historique d’analyse et de détection

Dans le processus précédent, la phase d’analyse est réalisée manuellement la plupart du temps grâce à des outils de visualisation et d’exploration de la donnée.

On peut distinguer 3 niveaux d’analyse :

• Local (micro) : Le serveur Nginx qui a généré ce log a reçu une requête mal formée.
• Global (macro) : Cette IP a généré 400 requêtes sur nos serveurs depuis le début de l’enregistrement.
• Régional (meso) : Ce serveur Nginx a été contacté par 60 IPs dans les 2 dernières minutes.

La plupart des outils classiques permettent d’analyser d’un point de vue statistique macro ou meso les données, et de générer des séries temporelles micro de certains champs de logs.

En termes de détection, la plupart des outils offrent des règles correspondant à des seuils absolus ou relatifs sur des valeurs de champs ou statistiques globales. Il existe des outils qui permettent de faire des moyennes flottantes ou de détecter des anomalies statistiquement significatives. Cependant ces outils viennent souvent avec un choix a faire entre avoir beaucoup de faux positifs ou ne pas voir beaucoup d’erreurs.

Un nouveau paradigme d’analyse

Pour résoudre ce problème, on pourrait maintenant ajouter des outils de Machine Learning dans le workflow:

• Au niveau de l’analyse pour mettre en évidence des anomalies difficile à trouver pour un humain.
• Au niveau de l’alerting pour détecter des anomalies que les règles de détection classique n’arrivent pas à isoler.

Ce n’est cependant pas trivial. En effet, il est certes possible d’utiliser des algorithmes de ML directement sur les séries temporelles issues des logs ou sur les statistiques globales, mais cela n’est pas très efficace. On va donc avoir besoin de rajouter plusieurs étapes dans la chaîne de traitement pour pouvoir efficacement implémenter du Machine Learning.

Représentation numérique aka Numérisation

Pour pouvoir utiliser la plupart des algorithmes de Machine Learning, on a besoin de projeter nos objets représentant de la donnée comme des IPs ou des URLs dans un espace numérique. Ce processus peut paraître simple à première vue, mais il peut très rapidement devenir extrêmement complexe. Prenons l’exemple des IPs, une représentation naïve des IPs sur l’ensemble des réels serait :

f(IP) = f(A.B.C.D) = A*2**24 + B*2**16 + C*2**8 + D*2**0

Cependant cette représentation est mauvaise en termes de distance. On veut que deux IPs qui ne se “ressemblent pas” soient éloignées. Ici, 9.254.254.254 et 10.0.0.0 seraient représentées proches, alors que l’une est une IP publique, et l’autre une IP privée. Cette représentation est aussi problématique du point de vue des collisions puisque l’espace des IPs est composé d’amas d’IP très denses interposées de grands vides. On risque donc d’avoir beaucoup de mal à représenter graphiquement l’ensemble des points sur une dimension.

Une représentation plus intéressante pourrait être f(IP)= f(A.B.C.D) = [A,B,C,D, Type]. On représente l’ensemble des IPs sur 5 dimensions, une par octet, puis une supplémentaire avec la logique :

• Unicast = 1
• Loopback = 2
• Multicast = 3
• Private = 4
• Reserved = 5
• Other = 6

f(192.168.1.1) = (192,168,1,1,4)

Cet exemple nous montre qu’il manque de nombreux outillages dans le cycle de traitement des logs. Nous avons abordé la question des IPv4 mais on pourrait se poser la même question pour les adresses MAC ou IPV6 par exemple, qui sont aussi difficiles à représenter dans un espace numérique.

Enrichissement

Parser et numériser la donnée ne suffit pas, il faut l’enrichir pour pouvoir créer de nouvelles features (dimensions numériques) pour les algorithmes de ML. On distingue 3 types d’enrichissement :

1. Intrinsèque : Ce code d’erreur Apache est équivalent à une erreur de connexion.
2. Endemique : Ce hostname appartient à mon parc et est dans le VLAN 1001.
3. Externe : d’après une BDD de vulnérabilités, cette IP héberge le C&C d’un Botnet.

On peut aussi distinguer les enrichissements “objectifs” et “subjectifs”, c’est-à-dire les enrichissements qu’on peut considérer comme vrai avec un très fort taux de fiabilité (Exemples 1 et 2) de ceux qu’on a généré suite à une hypothèse ou avec un plus faible taux de fiabilité (Exemple 3).

Instrumentation

Il existe quelques outils open-source qui permettent de réaliser du point de vue technique ces taches, (Voir Punchplatform “Complex Event Processing” par exemple) mais il n’existe pas de Framework de développement permettant d’implémenter cette nouvelle chaîne facilement.

Conclusion

Avant d’arriver à aisément interfacer du Machine Learning dans les phases d’analyse et de détection de la chaîne de traitement des logs, il est nécessaire de traiter la donnée pour l’adapter à ce type d’algorithmes. Ce travail peut s’avérer long et fastidieux, car les données issues des logs informatiques sont complexes à transposer dans un espace numérique.

Je travaille actuellement sur le développement d’un Framework open-source en Python de log processing avec quelques collègues de CNS Communications et amis dans d’autres sociétés dans le but de faciliter ce procédé.

Constantin Vurli

Twitter : @flashybowtie