Log Analytics : analyser d’où vient sa volumétrie de données

La solution log Analytics est basée sur des agents qui vont collecter des données (configuration pour détecter les écarts par rapport aux recommandations comme AD, SQL… journaux d'évènements, compteurs de performance, trafic réseau, autre). Une fois collectées elles vont arriver dans la base de données de votre "Workspace" (coffre-fort) situé dans Azure, pour être ensuite analysées par vous et les packs d'intelligence mis à disposition par les équipes produit. Ces packs représentent donc une valeur très importante pour vous, car ils correspondent aux recommandations de l'éditeur Microsoft. Certains packs, comme ceux qui identifient les problèmes au sens large peuvent également remonter des alertes de logiciels tiers qui utiliseraient les journaux d’évènements comme véhicule d’information.

Que ce soit via votre abonnement Azure, ou mieux encore si vous disposez de la licence OMS (qui vous donne un crédit de stockage plus important), la solution se "facture" au Go stocké. Soit elle garde vos données pendant 1 mois (version standard), soit pendant 12 pour la version Premium.

La quantité de données est donc une question légitime car elle va entrainer un coût. Bien que dans des solutions de type SIEM la logique est que l'on collecte tout pour les stocker à long termes, et analyser ensuite.

Que ce soit pour des audits ou pour des déploiements, je me suis souvent demandé comment se répartissait en volume ces données collectées, puisque c'est l'unité de facturation. Ci-dessous mon analyse personnelle qui n'est en rien une position officielle de Microsoft ou des développeurs de la solution Log Analytics. Elle semble globalement bonne sur les déploiements que j'ai rencontré. Egalement, quelques explications et des optimisations possibles pour réduire cette volumétrie.

Comprendre le portail Log Analytics

Ci-dessous vous pouvez voir une illustration de ce portail. Dans l’un des carrés, est affichée une "quantité de données" (juste sous Solution Gallery). Cette volumétrie correspond à celle collectée depuis le même jour à minuit, c’est pour cela qu’elle va augmenter tout au long de la journée.

Ce que j'aime à dire à ce niveau c'est que "c'est la quantité de données envoyé par votre infrastructure à vos équipes IT pour la bonne santé de l’entreprise, mais ce sont des données que vous ne voyez jamais si vous n'avez pas une solution comme Log Analytics ou SCOM".

Pour voir réellement la volumétrie globale, il suffit de cliquer sur ce "bouton" et vous obtenez la fenêtre des détails (ci-dessous).

Les données collectées : détails.

Maintenant l'application vous montre plus de détails sur "votre" collecte de données. Il est juste impossible à l’avance (sans avoir testé quelques jours) de savoir quel sera la consommation, cela dépend strictement de votre infrastructure. Une astuce pourrait être d’utiliser Log Analytics en mode “FREE” mais on est alors limité à 500 Mo par jour ce qui est très peu. Pour le prix, passez en standard pour retirer cette limite !

Dans l’écran ci-dessous on voit les 30 derniers jours, mais surtout quel type de data prend quel volume au sein de cette base.

Attention, si vous l'avez déployé il y a 10 jours, il faudra faire un X 3 pour avoir une vision précise à 30 jours.

Sur ce Workspace de test, on peut voir que depuis 30 jours, on a collecté 265 GB : quelle volumétrie que je ne voyais pas auparavant !

Dans la documentation en ligne (https://azure.microsoft.com/fr-fr/pricing/details/log-analytics/), on peut voir les éléments tarifaires correspondant pour imaginer le coût de l’abonnement.

Ici, avec une rétention 1 mois nous donne donc en gros 2 euros x 265 soit 530 euros par mois.

Ceci est très important : ce prix représente à la fois le service de collecte, de stockage haut dispo, de puissance d'analyse (à chaque fois que vous envoyez une requête sur des millions d'enregistrements), mais aussi la valeur des packs d'intelligences qui reprennent les recommandations de l'éditeur. A ne pas comparer avec une solution gratuite, pour laquelle vous devez acheter le matériel et le stockage, faire les sauvegardes, mais surtout créer les règles une par une.

Les éléments de prix (comprend collecte, stockage, calcul, et pack d'intelligence)

Voici un extrait de la tarification. La version Gratuite est intéressante car souvent 7 jours d'historique suffisent pour faire un mini audit. Malheureusement, 500 Mo par jour de collecte oblige à ne pas activer les audits de sécurité au niveau de Log Analytics. Personnellement, je milite pour augmenter ce volume, quitte à réduire l'historique des données par exemple à 3 jours. Mais je ne suis pas décideur !

L'interface propose également une estimation de votre coût en fonction du "plan" sélectionné. Pour qu'elle soit efficace, il faut collecter plusieurs jours :

Maintenant entrons dans les détails. Ce même portail nous donne également plus d'informations sur la provenance de ces données, plus précisément leur répartition par type de données :

Ici nous voyons clairement que ces données proviennent massivement de la partie Sécurité pour un volume très important.

Affiner nos recherches : quelles sont ces données de sécurité ?

Tout d'abord, ces données sont les vôtres, toute celles mis à disposition par votre infrastructure et vos logiciels, et que vous ne regardez pas forcément.

En fonction de l'activité, de la configuration de vos serveurs, .. ce volume peut changer. Dans ce Blog je peux donner des tendances, mais rien ne vaut un déploiement sur votre environnement.

L'interface à ce jour malheureusement ne permet pas d'aller plus finement dans l'analyse, et c'est là ou nous pouvons utiliser directement une requête pour comprendre encore plus cette volumétrie.

Pour ce faire, sur le portail Log Analytics, aller dans Log Search et indiquez cette requête :

Type=SecurityEvent | measure count() by Activity

Vous aurez alors le résultat ci-dessous. Vous voyez dans mon exemple que la majorité des requêtes concerne des Login/Logout, ainsi qu'un warning sur des privilèges.

Notez ici la quantité d'event qui est généré par seulement 3 évènements.

Cette requête est une pour une journée, la même tendance se retrouve sur une semaine ou un mois.

A ce stade, nous comprenons que la volumétrie vient de la catégorie "Sécurité" et que 3 évènements sont visiblement très gourmand en quantité, et on peut l'imaginer également en volume.

Important : Dans Log Analytics, vous ne payez pas en fait au "stockage des données", mais a l'ingestion des données. Si en janvier vous avez envoyé 100 Go, vous serez alors facturé pour ce montant. Si en février vous avez encore 100Go, vous serez alors facturé pour le même montant… même si au total vous avez maintenant 200 Go dans la base en abonnement premium.

Maintenant quelles sont les solutions pour réduire cette volumétrie générée par 3 évènements ? En théorie, la logique des outils de SIEM est de tout collecter, pour analyser ensuite. Certes… Mais comment optimiser le tout (J’insiste : Il est important de se rappeler encore une fois que le "prix au Go" de Log Analytics c'est pour à la fois la collecte, le stockage, les packs d'intelligence, la capacité de calcul, etc)

Optimisations, Solutions et conclusions

Tout d'abord, mi-mai 2016 un certain nombre d'optimisations ont été mises en ligne pour améliorer cette situation. La quantité (nombre d'event) sera toujours la même car c'est en fait votre environnement qui fait parvenir ces message, mais le "poids" de chaque évènement a été allégé, en particulier sur les champs Metadata qui peuvent être volumineux.

Ensuite :

Si vous utilisez l'agent OMS Log Analytics(qui parle directement à Azure, ou passe via un relais centralisateur), à ce jour vous ne pouvez pas filtrer à la source, par exemple pour exclure ces 3 évènements ou spécifier les champs à remonter. Il faut être un peu patient, c'est dans la liste des fonctions demandées, mais pas de date de sortie.

En revanche, si vous utilisez un agent SCOM, il est possible de filtrer "à la source", et donc de ne pas récupérer des évènements précis (c'est un choix client, car ils ont une importance quand même).

Voici le lien de référence pour activer cette configuration de filtrage “à la source” sur SCOM : https://gefufna.wordpress.com/2016/04/12/how-to-selectively-collect-security-events-by-using-microsoft-operations-management-suite/, et la partie intéressante ici :

Maintenant, il est également possible de changer la configuration d’audit directement sur les serveurs ou via les politiques globales d’entreprise.

Voici les deux liens de référence selon moi sur le sujet :

https://technet.microsoft.com/en-us/library/dn487457.aspx

https://technet.microsoft.com/en-us/library/jj852202%28v=ws.10%29.aspx

Bonne mise en œuvre !