UBA – Définir les écarts de comportement grâce à l’analyse du comportement des utilisateurs

Depuis dix ans, les centres de sécurité et les analystes s’échangent des indicateurs de compromission (IoC), des signatures et des signes d’intrusion ou de tentatives d’intrusion basés sur des seuils pour essayer de suivre le rythme de l’environnement des menaces, en évolution constante. C’est peine perdue.

Dans le même temps, les hackers sont devenus plus efficaces à dissimuler leurs activités. Une technique de dissimulation, appelée stéganographie, a rendu pratiquement inutiles les mesures d’investigation traditionnelles basées sur la signature et les seuils.

Face à cette situation, le secteur de la sécurité a vu apparaître une demande portant sur une capacité d’Analyse du comportement des utilisateurs (UBA), qui examine les schémas d’activité et les différences mathématiquement significatives de comportement des utilisateurs (utilisation des applis, activités de recherche de fichiers), par rapport aux informations historiques de base.

On me demande souvent ce qui fait la différence entre l’UBA et les approches traditionnelles basées sur la gestion des événements et informations de sécurité (SIEM).

Connaître son histoire comportementale

D’après moi, la réponse est historique. Connaissez-vous cette citation qui dit que celui qui ne peut se rappeler le passé est condamné à le répéter ? Cela s’applique à une approche purement basée sur la SIEM qui examine les événements en cours : fichiers supprimés ou copiés, échecs de connexion, signatures de programme malveillant ou demandes de connexion excessives de la part d’une adresse IP.

Bien entendu, vous devez examiner les événements bruts mais, sans contexte, les statistiques et instantanés basés sur la SIEM ne constituent pas un signe fiable de ce qui se passe vraiment. Nous appelons « faux positifs » les cas où un système SIEM semble signaler une alerte lorsque tout est normal. À un moment donné, vous finissez par faire en permanence la chasse aux mêmes faux positifs ou, encore pire, par tous les ignorer d’un coup (« surdité »).

Quelle quantité de fichiers supprimés ou copiés par un utilisateur doit-on considérer comme trop élevée ? Quelle quantité d’échecs de connexion doit-on considérer comme inhabituelle pour cet utilisateur précis ? À partir de quel moment le fait qu’un utilisateur consulte un dossier rarement lu devient-il suspect ?

La décision essentielle qui doit être prise en cas d’une notification d’événement est le seuil adéquat pour distinguer le normal de l’anormal.

Souvent, il y a des dizaines, voire des centaines ou des milliers d’applications et d’accès utilisateur, qui ont chacun un objet unique et un ensemble de seuils, signature et alertes à configurer et surveiller. Une approche par force brute entraîne l’application de règles qui ne s’appuient pas sur des données passées mais sur des paramètres spécifiques paraissant corrects. Ce mode de fonctionnement génère des rapports sans fin et des lumières qui clignotent sur les tableaux de bord, qui nécessitent qu’une équipe trie les « fausses informations ».

Ce dilemme concernant la façon de fixer un seuil a conduit des chercheurs en sécurité à une approche statistique consistant à baser les seuils sur l’analyse de comportements utilisateur réels.

La principale différence entre l’UBA et les techniques de surveillance qui s’appuient sur des seuils statistiques est que la décision de déclenchement est guidée par des modèles mathématiques et une analyse statistique mieux à même de localiser les véritables anomalies, et donc de réduire les faux positifs. Quelques exemples d’alertes comportementales :

• Alerte émise lorsqu’un utilisateur accède à des données qu’il a rarement consultées auparavant, à une heure de la journée inhabituelle pour lui (un dimanche à 4h du matin), puis lorsqu’il les envoie à un FAI basé en Croatie
• Alerte émise lorsqu’un utilisateur présente des échecs de connexion non conformes au comportement normal
• Alerte émise lorsqu’un utilisateur copie des fichiers depuis le répertoire d’autres utilisateurs pour ensuite les déplacer sur une clé USB

Exemple simple d’UBA

La raison pour laquelle l’UBA est si efficace est qu’il ne dépend pas uniquement d’une analyse basée sur une signature ou un seuil statique.

Expliquons ceci par un exemple.

L’équipe de sécurité d’Acme Inc. a été chargée de surveiller les activités de messagerie électronique de l’ensemble de ses 1000 employés. Impossible, non ?

Pour comprendre l’ampleur du problème, portons notre attention sur seulement 5 utilisateurs (0,5 % de tous les utilisateurs). Pour commencer, nous appliquons une capacité d’analyse classique et examinons leur activité de messagerie électronique (ci-dessous) pendant une semaine.

En étudiant ce rapport, vous pourriez décider d’enquêter sur les utilisateurs qui ont envoyé le plus d’e-mails, n’est-ce pas ?

Vous vous rendez rapidement compte que Martine, qui a envoyé 90 e-mails le vendredi, fait partie de l’équipe marketing et que ses performances sont basées sur le nombre de clients qu’elle contacte par e-mail au cours de la journée. Fausse piste !

Vous décidez ensuite de prendre la moyenne de tous les utilisateurs pour chaque jour. Vous mettez en place une alerte basée sur un seuil statique lorsque l’utilisateur envoie plus d’e-mails que la moyenne pour un jour donné. Pour l’ensemble de données ci-dessus, le nombre moyen d’e-mails envoyés par un utilisateur pour une journée donnée est de 17.

Si vous créez une alerte pour qu’elle se déclenche à chaque fois qu’un utilisateur envoie plus de 17 e-mails au cours d’une journée, vous recevrez 6 alertes au cours de cette période. Quatre de ces alertes vous ramèneraient à Martine, la reine des e-mails.

De toute évidence, ce seuil est trop sensible. Vous devez mettre en place une stratégie non basée sur la moyenne brute pour tous les utilisateurs un jour donné — la colonne verticale.

L’algorithme de détection des anomalies de l’UBA examine chaque utilisateur, chaque jour, et enregistre des informations sur ses activités. Ces informations historiques, découpées par jour, heure et d’autres dimensions, sont conservées dans le système afin de pouvoir créer des statistiques de base.

C’est comme si l’outil UBA exécutait les rapports et déterminait les moyennes et les écarts types pour chaque utilisateur, les comparait avec ceux de leurs collègues et, le temps passant, signalait uniquement les utilisateurs et activités « sortant du lot ». L’UBA calcule aussi les moyennes, écarts types et autres statistiques de manière dynamique dans le temps afin qu’ils reflètent les changements éventuels dans les tendances historiques.

À titre d’exemple, voici une règle comportementale envisageable : signaler tout écart par rapport à l’activité normale d’un utilisateur au niveau de l’envoi des e-mails.

Elle peut être traduite plus précisément par « signaler quand un utilisateur se situe à plus de deux écarts types de sa moyenne ».

À l’évidence, ce n’est pas ce qui se fait en pratique – il existe des tests statistiques plus efficaces et des analyses plus révélatrices.

Le point le plus important est qu’en examinant les utilisateurs ou un ensemble d’utilisateurs appartenant aux mêmes groupes Active Directory, l’UBA peut identifier les véritables anomalies avec plus de précision et les signaler.