Analyse du comportement des utilisateurs avec l’apprentissage automatique

Introduction

En 2023, le rapport DBIR a découvert que 86 % des violations Web se produisaient en raison d’informations de connexion volées. Alors que la prévention des attaques reste un aspect vital des mesures de sécurité globales, DataSunrise offre des mécanismes améliorés pour la surveillance des comportements suspects des utilisateurs de bases de données.

Les bases de données manifestent souvent des informations d’identification d’utilisateur compromises ou des systèmes infectés à travers des tentatives d’élévation de privilèges ou d’accès à différentes bases de données ou schémas, tels que ‘pg_catalog’. Une situation courante survient lorsqu’un utilisateur tente d’accéder à la base de données depuis une adresse IP inconnue. Cela indique souvent une activité suspecte, possiblement due à des informations d’identification d’utilisateur compromises.

La tâche de comportement d’utilisateur suspect de DataSunrise utilise des outils d’apprentissage automatique (ML) pour surveiller le comportement des utilisateurs et traiter efficacement les cas suspects. Son approche d’apprentissage automatique facilite une configuration flexible de l’outil sans avoir besoin de configurer manuellement des ensembles d’adresses IP en liste blanche ou des bases de données et schémas autorisés pour des utilisateurs spécifiques. Cela élimine la nécessité de configurer manuellement des adresses IP ou bases de données.

Auditer l’activité de la base de données

Avant de discuter de la surveillance du comportement, nous devons noter comment nous collectons les données d’entraînement ML. DataSunrise dispose d’un outil appelé Audit qui enregistre l’activité. Vous pouvez trouver les journaux dans Audit → Trails transactionnels.

Les journaux d’audit de DataSunrise enregistrent les données pour suivre comment les utilisateurs de la base de données se comportent généralement et peuvent également aider à surveiller toute activité suspecte.

Les données collectées sont basées sur du texte et souvent trop volumineuses pour être analysées sans outils spécifiques d’analyse de données. DataSunrise a tout ce dont vous avez besoin pour traiter de grandes quantités de données et tirer des conclusions à partir des insights fournis.

Pour créer une tâche de comportement suspect d’utilisateur, vous avez besoin des bonnes données d’entraînement à partir des Trails transactionnels. Vous devez également exécuter la tâche d’analyse du comportement dans la plage de temps correcte.

Lors de la première exécution, la tâche entraîne le modèle statistique. Les exécutions ultérieures impliquent l’analyse des Trails transactionnels de la fin de la plage d’entraînement à la fin des Trails transactionnels.

Outils ML pour la surveillance du comportement des utilisateurs : étude de cas

Le scénario est le suivant : La société utilise une application web avec une base de données pour gérer les données des clients. La société vérifiera régulièrement toute activité inhabituelle dans les tables de la base de données, soit à la main soit toutes les heures.

Il y a trois étapes principales pour implémenter la tâche d’analyse du comportement des utilisateurs :

Étape 1 : Créer une règle d’audit pour surveiller les requêtes via le port proxy vers la base de données de ressources. Trouver une période de formation appropriée basée sur les Trails transactionnels des règles actives. Il s’agit d’une étape préliminaire nécessaire pour fournir le jeu de données d’entraînement.

Dans une configuration typique de DataSunrise, il y a plusieurs règles d’audit et d’extensives journaux de Trails transactionnels. Ainsi, l’utilisateur peut vérifier que les Trails transactionnels pour la période choisie ne montrent que l’activité approuvée.

Étape 2 : Créer une tâche de comportement d’utilisateur avec une période de formation appropriée. Configurer la tâche pour l’exécuter pour la première fois pour entraîner le modèle statistique.

Étape 3 : Exécuter certaines activités inhabituelles en utilisant des outils tiers comme ‘psql’ ou ‘DBeaver’. Ensuite, exécutez manuellement la tâche à nouveau pour l’analyse. Cela aide à s’assurer que la règle fonctionne correctement.

L’hôte de comportement normal (du côté gauche de l’image) contient une application web. Cet hôte sert généralement d’instance de serveur connecté à la base de données via l’hôte de pare-feu (au centre). Nous avons installé DataSunrise sur l’hôte de pare-feu, et ses Trails transactionnels enregistrent les connexions à la base de données via le port proxy DataSunrise 5432.

Étape 1: Règle d’Audit pour les actions régulières

Pour créer une règle d’audit, allez d’abord à l’interface utilisateur basée sur le Web de DataSunrise. Puis, cliquez sur Audit, ensuite Règles. Enfin, cliquez sur +Ajouter une règle si elle n’est pas déjà là.

Vous devez activer l’AuditObject dans Paramètres système – Paramètres supplémentaires. La règle d’audit doit suivre uniquement les actions approuvées des utilisateurs pour l’entraînement. Les utilisateurs peuvent toujours le vérifier dans les Trails des transactions plus tard.

Activez la règle que vous venez de créer. Les requêtes vers la base de données devraient apparaître dans les événements de la règle. Au cours de cette étape, nous analysons les Trails transactionnels et sélectionnons la période d’activité normale pour l’entraînement au comportement suspect de l’utilisateur.

Étape 2: Tâche de comportement suspect de l’utilisateur

Maintenant que nous avons vérifié que les données d’entraînement sont présentes et sélectionné la période de formation, il est temps de créer une tâche de détection de comportement suspect de l’utilisateur. Pour ce faire, accédez à Configuration – Tâches périodiques – +Nouvelle tâche.

Dans la liste des types de tâches, sélectionnez Détection de comportement suspect de l’utilisateur. Le seul paramètre requis ici est de définir la plage des événements du jeu de données d’entraînement. Par ailleurs, il y a une option de fréquence de démarrage pour la tâche, mais dans notre cas, où nous exécutons la tâche manuellement selon les besoins, nous pouvons laisser la fréquence à la valeur par défaut (horaire).

Ci-dessous, la configuration de la période de la nouvelle tâche de comportement suspect de l’utilisateur.

Nous définissons la période pendant laquelle seules les activités autorisées se produisent sur tous les proxys de l’instance de base de données. Ces activités sont celles en liste blanche, et nous avons sélectionné les heures de premier et dernier événement lors de l’analyse à l’Étape 1.

Pour initier l’entraînement du modèle statistique de la tâche, enregistrez les paramètres. Cette action vous redirigera vers la section des tâches périodiques. Naviguez à nouveau vers la tâche de comportement suspect de l’utilisateur en cliquant sur son nom dans la liste. Ensuite, appuyez sur ‘Exécuter‘ pour exécuter la tâche et vérifier son statut.

Il ne devrait y avoir aucune erreur. Lors de la première exécution de la tâche, elle ne détecte aucune activité suspecte car elle se concentre uniquement sur l’entraînement du modèle statistique. Dans le dialogue de la tâche lors de l’exécution de la tâche, l’utilisateur peut observer la progression de l’entraînement dans le message de statut.

Cela conclut l’Étape 2. Nous avons maintenant le réseau entraîné dans la tâche de comportement suspect de l’utilisateur et pouvons procéder à l’enregistrement effectif de la détection de comportements suspects.

Étape 3: Activité suspecte et analyse

Dans notre cas, l’activité suspecte concerne les requêtes d’une adresse IP inattendue (hôte d’activité malveillante) accédant à tous les champs de ‘pg_catalog.pg_enum’.

Pour se connecter à la base de données arbitraire depuis l’adresse IP suspecte de l’hôte d’activité malveillante, la commande ‘psql’ de cet hôte a été utilisée :

/usr/pgsql-13/bin/psql -h 192.168.10.104 -p 5432 -U ubuser01 -d ubdb02
ubdb02=# select * from pg_catalog.pg_enum

En conséquence, un seul avertissement de session apparaît dans les résultats de la tâche de comportement suspect de l’utilisateur :

Veuillez noter que si l’utilisateur de l’hôte d’activité malveillante se connecte au proxy en utilisant un logiciel comme DBeaver ou tout autre logiciel de gestion de base de données basé sur une interface utilisateur, cette action déclenchera également des avertissements. DBeaver vérifie automatiquement la structure de la base de données. Il exécute des requêtes sur des tables et schémas qui ne sont pas présents dans les données d’entraînement. Le système peut signaler une activité inattendue en conséquence.

Dans ce scénario, des requêtes de base de données ont été effectuées deux fois par proxy DataSunrise depuis l’hôte de l’application Web de comportement normal. Par la suite, une connexion à la base de données a été établie à l’aide de DBeaver depuis une adresse IP de confiance. Cependant, DBeaver a poursuivi les requêtes sur des tables et schémas inhabituels (pg_catalog). Par conséquent, nous avons signalé ces sessions comme suspectes.

La tâche de comportement suspect de l’utilisateur peut générer des alertes pour tous les proxys de l’instance de règle d’audit de la base de données, ou pour les règles et instances s’il y en a plusieurs. Il est important de noter que dans les résultats (figure ci-dessus), le numéro de port de la base de données représente le port du serveur de base de données défini dans la configuration de l’instance pour la connexion à la base de données protégée. Cela n’est pas le port proxy de cette instance.

Pour vérifier si tous les proxys d’instance génèrent des alertes de comportement suspect, les utilisateurs doivent effectuer des requêtes suspectes sur tous les ports proxy, s’assurer qu’ils sont audités, et relancer la tâche de comportement suspect de l’utilisateur. Ensuite, cliquez sur l’icône de mise à jour dans la liste des résultats de la tâche. À mesure que de nouvelles requêtes apparaissent, cliquez sur l’ID de session pour trouver le numéro de port proxy.

Toutes les requêtes et les lignes affectées sont disponibles dans les détails de la session quand on clique sur le tableau des résultats de la tâche. Veuillez vous référer à la figure ci-dessous pour plus de détails.

Résultats du cas

Nous pouvons identifier des sessions suspectes en examinant des paramètres de requêtes inhabituels tels que les adresses IP ou les noms de bases de données. Ces paramètres s’écartent de l’activité typique observée pendant la formation dans la tâche de comportement suspect de l’utilisateur.

Les principales conclusions du cas sont les suivantes :

• Le modèle statistique se concentre sur l’analyse des adresses IP, tables, schémas, etc., au sein des requêtes. Il ne prend pas en compte le contenu des requêtes elles-mêmes. Par exemple, le modèle statistique entraîné sur des requêtes SELECT simples ne signalera pas des requêtes SELECT complexes ou des requêtes « SELECT all » sur la même table comme suspectes. Cela parce qu’elles proviennent d’adresses IP appropriées et sont dirigées vers des bases de données inhabituelles.
• Les instances de la règle d’audit déterminent les proxys potentiels pour marquer les sessions entrantes comme suspectes. Il est crucial que le jeu de données d’entraînement couvre toutes les sessions régulières raisonnables pour tous les proxys. Les sessions de proxy inconnues seront signalées comme suspectes.
• Aucune configuration spécifique n’est requise pour entraîner la tâche de comportement suspect de l’utilisateur sur une règle d’audit particulière. Tous les enregistrements de transactions dans le jeu de formation d’audit sont utilisés pour enseigner au réseau. Ces enregistrements aident également à identifier de nouveaux événements et de les envoyer à la tâche de comportement suspect de l’utilisateur pour une investigation plus poussée.

Dépannage

Voici quelques points à noter :

• Utilisez JVMChecker pour vérifier si Java fonctionne correctement (situé dans /opt/datasunrise/bin).
• Utilisez les journaux de comportement d’utilisateur pour analyser si l’exécution de la tâche a produit des messages d’erreur. La tâche de comportement suspect de l’utilisateur a un fichier journal pour les messages d’erreur. Vous pouvez le trouver dans les paramètres système sous Journalisation & Journaux, puis Type de journaux, et enfin Détection de comportement suspect de l’utilisateur.
• N’oubliez pas d’activer la propriété avancée ‘Audit Objects’ lorsque la tâche de comportement utilisateur s’exécute pour la première fois.
• Comprenez vos données. Le processus d’entraînement nécessite une quantité relativement grande de données dans les journaux d’audit. Analyser la partie texte des requêtes SQL est important à noter. Cela signifie qu’il n’y aura pas d’alarme pour des tables ou colonnes inhabituelles dans une requête SELECT s’il est réalisé sur la bonne base de données, depuis la bonne IP, et par le bon utilisateur et application.
• Lors de la première exécution de la tâche de comportement utilisateur, assurez-vous que le registre d’audit ne contient que de l’activité autorisée. Si nécessaire, l’utilisateur peut facilement recréer la tâche de comportement utilisateur et entraîner son modèle statistique à nouveau.

Conclusion

La tâche de comportement utilisateur suspect basée sur le ML aide à surveiller l’accès aux données en configurant automatiquement des règles pour différents utilisateurs. Cela fait gagner du temps et des efforts, surtout avec de grands jeux de données. Le pare-feu de base de données DataSunrise utilise efficacement des outils de ML pour la surveillance du comportement des utilisateurs. Malgré la complexité sous-jacente des processus impliqués, l’interface utilisateur basée sur le Web offre une interface conviviale pour configurer les tâches et analyser les sessions entrantes.

La tâche de comportement utilisateur suspect permet de scanner les Trails transactionnels DataSunrise pour déceler toute activité inhabituelle des utilisateurs actuels. Cela peut vous aider à identifier des brèches de sécurité potentielles. Vous pouvez effectuer ce scan régulièrement ou manuellement. Cet outil permet aux utilisateurs de marquer des sessions comme suspectes ou normales et d’apporter de petits changements pour simplifier l’interface.

Dans cet article, nous avons brièvement discuté de la configuration de la tâche de comportement utilisateur suspect. N’hésitez pas à visiter notre site Web et à demander une démo en ligne pour une discussion supplémentaire sur les solutions de sécurité des bases de données DataSunrise.