Big Data : panorama des cas d’usage Splunk

Par sa capacité à répondre aux enjeux du Big Data tant au niveau des DSI que des directions métier, Splunk a su séduire les équipes de D2SI et c’est dans cette optique que D2SI a développé il y a plusieurs années un partenariat avec Splunk.  Dans le cadre de ce partenariat, j’ai été amené à suivre il y a 2 ans une formation menant à la certification SCC2, permettant de délivrer pour le « Splunk Professional Services » et qui assure à nos clients un niveau de prestation aux compétences égales à celui de Splunk. Les cas d’usage décrits ci-dessous, liés à la sécurité, à des données métiers ou industrielles, sont ceux rencontrés dans le cadre des prestations réalisées pour le Splunk Professional Services.

Splunk Enterprise Security

Parmi les besoins les plus récurrents chez les clients, citons tout d’abord la sécurité. Evidemment, Splunk ne se substitue pas aux différentes solutions et équipements de sécurité du SI, mais sa solution SIEM Splunk Enterprise Security permet un traitement des logs de sécurité collectés au sein de l’entreprise : accès réseau, équipement de détection d’intrusion, activités mails, solutions malware, gestion des antivirus, remontées de notification… En effet généralement les SI multiplient les solutions et la difficulté consiste à centraliser les informations générées par ces multiples outils. L’avantage de la solution SIEM Splunk est donc de collecter, centraliser et traiter tous ces données, issues des softwares et/ou des équipements de technologies différentes, mais dédiés à la sécurité.

Faire remonter l’ensemble de ces données dans Splunk représente une charge assez importante, mais une fois que tout est centralisé, il est simple de mettre en place des règles de corrélation permettant de détecter les événements anormaux, qu’ils soient initiés par des machines ou par des humains. L’horaire de connexion inhabituel d’un utilisateur peut ainsi révéler une tentative d’intrusion, les attaques en bruteforce peuvent être prévenues en définissant un seuil du nombre d’authentifications en échec avant de lancer une alerte. Autre possibilité, la détection de pièces jointes avec du code malveillant, l’analyse des volumes de trafic réseau inhabituels… Sur ce dernier cas, on peut soit définir manuellement le seuil d’alerte, soit faire appel au machine learning de Splunk afin d’effectuer une analyse comparative sur une période passée, et de déterminer s’il doit y avoir alerte ou pas. Ce paramétrage est simplifié par l’existence de nombreuses règles de corrélation par défaut dans l’outil Splunk, avec une base très large répondant à une majorité des cas d’usage rencontrés chez nos clients. En fonction des besoins, il est également possible de modifier légèrement ces règles pour répondre à des attentes spécifiques (comme de définir soi-même un seuil d’alerte pertinent pour le client). Ce travail s’effectue en collaboration avec le client, qui doit savoir exactement ce qu’il veut détecter. Il est souvent difficile de mettre en place d’emblée les règles et les seuils adaptés, cela demande le plus souvent un peu d’ajustement dans le temps. Il existe environ 60 règles dans Enterprise Security, qui couvrent une dizaine de scopes : trafic réseau, sessions réseau, emails, certificats, détection d’intrusion, résolution DNS, firewall, antivirus…

Ces règles de détections s’accompagnent de nombreux tableaux de bords permettant aux équipes sécurité de connaître l’état de la sécurité de l’entreprise de manière globale puis précise, par exemple dans le cadre d’investigation suite à une alerte.

Dashboard Splunk Enterprise Security

Dashboard Splunk Enterprise Security

Analyse des données métier

Autre cas d’usage fréquemment rencontré, celui de l’exploitation de données métiers issues de différents systèmes. J’ai ainsi été confronté à la problématique d’un client souhaitant centraliser des données issues d’un ERP. L’objectif était de centraliser toutes les actions réalisées sur le système, mais la difficulté résidait dans le format des logs. Ces logs, spécifiques à l’ERP et au client, ne pouvaient pas être interprétés tels quels, et il n’existait pas non plus d’add-on Splunk permettant d’exploiter les logs. Comment interpréter ces logs dans leur formatage spécifique, et extraire la donnée afin de répondre aux besoins du client, à savoir de retranscrire l’intégralité des transactions sur l’ERP ? La complexité est ici apportée par le volume : sur 1 million de logs, il n’y a peut-être que 4 ou 5 transactions à exploiter. Ici Splunk prend tout son sens avec des fonctionnalités permettant de faire des corrélations facilement, et de sortir des informations exploitables pour le client : statistiques sur l’utilisation, sur les différents scopes métier, sur le taux d’utilisation de l’ERP, sur les durées des transactions complètes… Dans ce dernier cas, cela permet d’identifier un dysfonctionnement de l’application. Par exemple, sur un intervalle de 2 mois, on constate que 600 transactions sur 1,8 millions ont une durée anormale, et donc ne se sont pas correctement déroulées.

J’ai également eu à traiter le cas d’une application destinée au traitement des commandes et suivis clients, générant de nombreux logs dans un format propriétaire. Dans le cas de cette plateforme, ouverte à plusieurs centaines d’utilisateurs répartis sur différents sites en France, il a été décidé de reformater les logs de manière à simplifier la reconnaissance des transactions. L’exploitation de ces données dans Splunk a ensuite permis d’accéder à l’ensemble de l’historique du client. Dans cet exemple, l’implication du client a été un facteur déterminant de succès : sa connaissance des logs a permis de se dispenser d’un travail d’étude et de compréhension des logs nécessairement long quand certaines indications des logs n’ont de sens que pour le client. Autre facteur de réussite, comme souvent dans l’exploitation de données en grand volume : il faut savoir ce que l’on cherche. Dans ce cas, la centralisation des données dans Splunk a apporté comme bénéfice au client de pouvoir accéder à l’ensemble de l’historique facilement, et d’identifier rapidement et simplement les anomalies.

Exploiter des données issues de machines industrielles

Nous avons vu les challenges qui peuvent être posés par l’interprétation de logs issus d’applications métiers, et comment Splunk peut répondre à cette problématique. Mais il existe des cas de logs encore plus complexes, ceux issus de machines industrielles. Dans le cas que j’ai rencontré, non seulement ces logs n’étaient pas reformatables, mais comme il s’agit de données mathématiques, issues de machines industrielles, elles ne sont pas exploitables telles quelles : il s’agit de séries de chiffres, uniquement séparées par des marqueurs ! Le client disposant d’une table référentielle permettant de faire correspondre une série de chiffres à un modèle ou à une référence, les tables de correspondances ont été massivement utilisées pour réinterpréter la totalité des logs et les traduire en spécifications produits. Cela nous a permis d’extraire les informations, de les traiter et de faire un suivi de toutes les actions réalisées par les machines (historisation des modèles, etc.), et de générer des tableaux de bords et des indicateurs sur la production. Ainsi, il est devenu possible de comparer les dimensions, la matière et les types de finition pour chaque objet façonné au temps de fabrication. Et ainsi identifier les possibles points de ralentissement dans la production, la durée de fabrication étant un point stratégique pour l’entreprise. Autre information à croiser avec les données issues de la fabrication, celle des taux de retour : l’extraction des logs a ici permis d’identifier des problèmes récurrents sur certains processus industriels particuliers. Enfin, et ça n’est pas le moindre des apports, l’analyse des logs en temps réel permet de suivre l’évolution des stocks de matière première pour chaque site et d’optimiser la chaîne logistique.

Comme on le constate, les cas d’application de Splunk en entreprise sont nombreux : la donnée est une précieuse matière première qu’il faut savoir capter et exploiter. Nous avons vu ici des contextes liés à la sécurité, au métier, ou à l’analyse de données industrielles, mais toute la DSI est concernée : qu’il s’agisse d’Active Directory, de DNS, DHCP ou de management de certificat, toutes ces données peuvent être traitées par Splunk dans le cadre du monitoring IT. Idem pour les équipements réseau (firewall, routeurs, switch), serveurs et postes de travail, au sein des Datacenters clients ou sur le Cloud : le déploiement de Splunk sur AWS, c’est déjà une réalité chez D2SI !

Pour vous inscrire à la formation Splunk 4 Rookies :

Commentaires :

A lire également sur le sujet :