Analyse temporelle ou de population avec le machine learning d'Elastic
Le machine learning d'Elastic permet aux utilisateurs de découvrir principalement deux sortes d'anomalies : celles qui sont de nature temporelle (en rapport au temps) et celles qui se rapportent à la population (soit toutes les autres). Que différencient ces deux types d'analyse, et dans quelles circonstances utiliserions-nous un type plutôt que l'autre ? Ce blog se penche sur les détails qui se cachent derrière les analyses, leurs avantages et les bonnes pratiques basées sur des recommandations d'ordre général.
D'abord, définissons les anomalies temporelles et de population. Pour ce faire, exposons quelques faits :
Détection des anomalies temporelles
- Il s'agit du comportement par défaut du machine learning d'Elastic, à moins que vous choisissiez spécifiquement l'analyse de population.
- Elle compare le comportement d'une entité sur la durée.
- Elle peut tirer profit d'une "partition" (au moyen de "byfieldname" ou de "partitionfieldname") pour créer des points de comparaison individuels pour chaque instance d'un élément (c.-à-d. un seul point de comparaison par hôte ou utilisateur).
- Elle ne convient pas vraiment aux éléments de données très dispersés ou dont la cardinalité est élevée (c'est le cas des adresses IP externes des visiteurs d'un site Web, avec des centaines de milliers de valeurs différentes, voire davantage). Elle cause des problèmes de performance si les limites de la mémoire de la tâche ne sont pas augmentées au-delà des limites par défaut. Même si vous procédez à cette augmentation, il est probable qu'une analyse de population soit plus appropriée.
Détection des anomalies de population
- Elle est appelée uniquement lorsque "overfieldname" est utilisé (ou lorsque l'assistant de création de tâches Population est utilisé dans Kibana). Le champ déclaré en tant que "overfieldname" définit la population.
- Il s'agit d'une analyse des membres d'une population ou, pour être plus exact, d'une comparaison sur la durée d'une entité individuelle par rapport à un modèle collectif de toute la population.
- Elle peut aussi tirer profit d'une "partition" (au moyen de "byfieldname" ou de "partitionfieldname") pour créer des sous-populations.
- Elle convient généralement aux éléments de données dispersés ou dont la cardinalité est élevée, car chaque membre prend part à un modèle collectif de comportements.
Cas d'utilisation
Penchons-nous désormais sur un cas d'utilisation hypothétique qui devrait nous aider à choisir la bonne approche.
Imaginons que nous souhaitons suivre le nombre de documents téléchargés à partir d'un serveur interne de documents et supposons que ce dernier contienne des documents qui, dans l'ensemble, s'appliquent à tous au sein de l'entreprise (soit plus de 50 000 employés). En outre, quiconque peut accéder à tout moment à ce serveur de documents. Enfin, supposons que le log d'accès au serveur de documents enregistre chaque accès à chaque document ainsi que l'utilisateur associé.
Exemple d'anomalie temporelle
Imaginons que nous optons pour la détection des anomalies temporelles et que nous élaborons une analyse du type :
"detectors": [
{
"function": "count",
"partition_field_name": "user"
}
]
Nous pourrons suivre sur la durée le nombre de téléchargements par utilisateur et par nom, de façon individuelle. Ainsi, si Wilma (user="Wilma") télécharge environ 50 documents par jour (elle travaille au bureau d'études et utilise très souvent les documents du serveur), il serait anormal qu'elle change radicalement son comportement et se mette à télécharger beaucoup moins ou beaucoup plus de documents qu'à l'ordinaire (5 000 documents par jour par exemple).
Aussi, tout comme nous l'avons déjà mentionné, nous devons prendre en compte le nombre d'utilisateurs distincts que le machine learning doit suivre. Nous devrions être en mesure de traiter 50 000 utilisateurs uniques en augmentant la limite de la mémoire de la tâche de machine learning. Toutefois, n'oublions pas que les utilisateurs ne téléchargeront pas nécessairement le même nombre de documents tous les jours. Leur activité peut être assez irrégulière. Il se peut qu'un utilisateur télécharge quelques documents aujourd'hui, puis qu'il n'en télécharge aucun pendant des mois. Il est difficile d'établir un point de comparaison précis par utilisateur si nous ne disposons pas d'observations concordantes pour chacun d'eux.
Mais surtout, qu'en est-il si une nouvelle personne (user="Fred") télécharge 5 000 documents en une journée, puis ne télécharge plus aucun document par la suite ? S'agit-il d'un comportement inhabituel ? Fred constitue-t-il une menace interne ou un programme malveillant a-t-il utilisé les informations d'identification de Fred pour voler un ensemble de documents afin de les transférer hors de l'entreprise ? Avec la détection des anomalies temporelles, nous ne pouvons pas trancher la question, car nous ne savons pas si le comportement de Fred est inhabituel. Nous ne pouvons effectuer aucune comparaison, car nous ne disposons pas d'un historique concernant cet utilisateur (nous disposons que d'un échantillon).
Exemple d'anomalie de population
Imaginons désormais que nous abordons le problème en recourant à la détection des anomalies de population de la façon suivante :
"detectors": [
{
"function": "count",
"over_field_name": "user"
}
]
Nous pouvons accomplir ce qui suit :
- Nous pouvons utiliser les données de tous les utilisateurs présents dans chaque "bucket_span" (ici, une journée) pour construire un modèle collectif du nombre typique de téléchargements effectués dans l'ensemble par les utilisateurs.
- Nous pouvons comparer les données quotidiennes de chaque utilisateur au modèle collectif.
Dans ces conditions, si Wilma et la majorité de sa cohorte téléchargent entre 10 et 75 documents par jour, le modèle collectif global d'utilisation typique correspond à cet intervalle. Si un jour Fred télécharge 5 000 documents, ce comportement sera considéré comme anormal, car les données de Fred sont comparées à celles de Wilma et de sa cohorte. Le comportement de Fred sera considéré comme une anomalie.
Toutefois, il est important de comprendre que si Wilma télécharge 5 000 documents à la place de Fred, le comportement de Wilma sera signalé comme anormal, car le nombre de téléchargements qu'elle a effectué dépasse le modèle type d'utilisation qu'elle et sa cohorte ont permis d'établir au fil du temps, et non parce qu'elle a téléchargé plus de documents qu'à son habitude.
Il convient de préciser que le comportement de Wilma est signalé comme anormal dans cette situation quel que soit le type de détection choisi, mais l'approche de population offre plus de flexibilité dans ce cas, car :
- Elle n'est pas sensible à la dispersion des données.
- Elle est plus efficace en matière de mémoire lorsque le nombre d'utilisateurs distincts est élevé, et ce, car les modèles individuels par utilisateur ne sont pas nécessaires.
- Elle permet de signaler des anomalies comme le comportement de Fred en disposant de peu ou d'aucune donnée historique.
- Elle permet de considérer le comportement de Wilma comme anormal si celui-ci change soudainement au point de ne plus correspondre au comportement collectif.
Conseil supplémentaire : si vous effectuez une analyse de population, construisez vos populations de la façon la plus homogène possible. Dit autrement, si vous disposez de grands clusters de types d'utilisateurs (par exemple, des ingénieurs et du personnel RH), il pourrait être plus efficace de répartir ces utilisateurs dans des groupes différents et d'effectuer deux analyses indépendantes plutôt que de les rassembler.
Enfin, si vous avez identifié à l'avance des membres d'une population que vous souhaitez exclure, envisagez de filtrer les données d'entrée ou d'utiliser des règles pour filtrer les résultats.
Nous espérons que cette explication vous a permis de comparer ces deux approches. Si vous souhaitez utiliser le machine learning avec vos données, téléchargez la Suite Elastic et activez la licence d'essai de 30 jours ou essayez gratuitement Elastic Cloud.