Azure AD Identity Protection

1- Introduction

Depuis quelques jours Azure Active Directory s’est enrichi d’un nouveau service (en mode preview) permettant de mettre en place un suivi des comptes de vos utilisateurs . Je vous propose donc au travers de cet article de faire plus ample connaissance avec les fonctionnalités offertes par le nouveau service Identity Protection exposé par Azure AD.

2- Azure AD Identity Protection

Le but de ce nouveau service est de permettre d’être alerter sur des comptes qui ont potentiellement été corrompus. Pour ce faire le service Identity Protection se base sur des algorithmes de machines learning afin d’analyser les différents événements se produisant sur l’ensemble des comptes hébergés sur votre tenant Azure Active Directory, et détecter de potentielles anomalies.

Parmi ces événements on peut trouver :

  • Des tentatives de connexions en échecs suivis d’une connexion réussie.
  • Des connexions simultanées depuis des localisations géographiques différentes.

A partir de ces différents éléments, un reporting est effectué dans le but de remonter les potentiels problèmes pouvant émaner de certains comptes avec un ensemble d’information permettant aux administrateurs de prendre connaissance des éléments remontés afin de pouvoir prendre une décision par rapport à ces comptes.

En plus de cette partie reporting, Azure AD Identity Protection s’occupe aussi de mettre en place des niveaux de risques pour chaque utilisateurs, et de mettre en place des politiques de sécurités par rapport à différents critères qui seront appliquées automatiquement, permettant ainsi d’automatiser la résolution automatique des risques.

Chacun des risques remontés possède un niveau de criticité parmi 3 niveaux qui sont définis au niveau de Identity Protection. Ces niveaux de criticité sont les suivants :

  • Faible
  • Modéré
  • Critique

Par rapport à ces différents niveaux, des actions peuvent  être mise en place avec notamment la possibilité  de bloquer un compte,de mettre en place une authentification multifacteurs, ou encore de réinitialiser le mot de passe.

2.1- Type d’événements remontés

Nous allons maintenant rentrer un peu plus dans les détails et voir dans un premier temps les différents types d’incidents qui sont traités par Identity Protection.

La version actuelle du produit concerne 6 types d’incidents qui sont les suivants :

Comptes compromis : ce type d’incidents est remonté quand un compte utilisateur est détecté comme étant compromis. Lorsque ce type de faille remonte pour un compte cela indique que les informations du compte sont publiquement accessible sur le dark web. Le niveau de gravité de ce type d’incident est sévère.

Connexion depuis deux localisation géographique différentes impossible : ce type d’incidents est remonté quand un compte utilisateur est utilisé à deux emplacements géographiques différents dans un laps de temps physiquement impossible. Afin de ne pas remonter de faux positifs, une analyse des comportements concernant les connexions utilisateurs est effectuée durant approximativement les 14 premiers jours d’utilisation du service. Le niveau de gravité de ce type d’incident est moyen.

Connexion depuis un périphérique infecté : ce type d’incidents est remonté quand un compte utilisateur est utilisé depuis une adresse IP connue pour se connecter à des serveurs de bots. ce type d’alerte est lié à une adresse IP est non à un device. Le niveau de gravité de ce type d’incident est faible.

Connexion depuis une adresse IP avec activité suspecte : ce type d’incidents est remonté quand de multiples tentatives de connexions en échec avec différents comptes se produisent dans un cours l’apse de temps depuis une même adresse IP. Le niveau de gravité de ce type d’incident est moyen.

Connexion depuis une adresse IP anonyme : ce type d’incidents est remonté quand utilisateur tente de ce connecter depuis un proxy anonyme. Ce type d’incident à un niveau de sévérité modéré.

Connexion depuis une localisation inhabituel : ce type d’incidents est remonté quand un compte utilisateur est détecte comme étant compromis. Lorsque ce type de faille remonte pour un compte cela indique que les informations du compte sont publiquement accessible sur le dark web. Le niveau de gravité de ce type d’incidents est sévère.

Après la partie théorique, je vous propose de voir un peu comment les choses se passent dans la pratique.

2- Exemple d’implémentation

Dans le but d’illustrer la façon dont sont remontés les informations concernant de potentiels problèmes au niveau des comptes, je vais effectuer une connexion vers une application protégée par mon tenant Azure AD depuis un proxy anonyme et regarder comment les informations sont remontées au niveau Identity Protection.

3.1- Gestion des règles

Afin de  gérer les différents événements qui sont remontés par Azure Identity Protection vous avez deux possibilités. Soit vous gérer les différentes alertes remontées de façon manuelle au fur et à mesure, soit vous définissez une politique de sécurité qui sera appliquée automatiquement par rapport au degré de gravité de l’alerte remontée. Pour se faire vous pouvez mettre en place des règles pour les deux catégories suivantes :

  • Risques liés à l’utilisateur.
  • Risques liés à l’authentification.

3.1.1 – Mise en place d’une règle pour la gestion des incidents liés aux comptes utilisateurs

Pour pouvoir activé cette règle, il vous suffit de cliquer sur tous les paramètres et ensuite de sélectionné, au niveau de la section « Security Policies« , l’option User Risk, et vous arriverez alors sur l’écran de configuration de la règle. Au niveau de cet écran vous pouvez dans un premier temps définir les utilisateurs qui seront impactés par la règles , et paramétrer aussi les utilisateurs qui seront exclus de cette règle. Ensuite vous pouvez choisir d’exiger un changement de mot de passe avec authentification multi facteur et définir le niveau d’alerte qui déclenchera cette action. Vous pouvez aussi définir un niveau d’alerte qui activera le blocage automatique de l’utilisateur lorsque un événement de niveau égal ou supérieur au niveau définit au niveau de la règle sera atteint.

A noter que si vous configurez le premier niveau de règle (changement de mot de passe), la règle concernant le blocage de l’utilisateur ne pourra être paramétrée qu’à un niveau d’alerte supérieur au niveau d’alerte de la règle définie pour le changement de mot de passe.

Vous pouvez ensuite voir un graphique montrant les utilisateurs ayant été impactés par les règles que vous aurez définies.

blog ai3 RegleUtilisateur Azure AD Identity Protection

3.1.2- Mise en place d’une règle pour la gestion des incidents liés à l’authentification des utilisateurs

Pour l’activation de cette règle, il vous suffit de cliquer sur tous les paramètres et ensuite de sélectionné, au niveau de la section « Security Policies« , l’option Sign-in Risk, et vous arriverez alors sur l’écran de configuration de la règle.

Au niveau de cet écran vous pouvez dans un premier temps définir les utilisateurs qui seront impactés par la règles , et paramétrer aussi les utilisateurs qui seront exclus de cette règle.

Ensuite vous pouvez choisir d’exiger une authentification multi facteur lorsque le niveau d’alerte atteint un seuil que vous aurez configuré au niveau de cette règle.

Vous pouvez aussi définir un niveau d’alerte qui activera le blocage automatique de l’utilisateur lorsque un événement de niveau égal ou supérieur au niveau définit au niveau de la règle sera atteint.

A noter que si vous configurez le premier niveau de règle (changement de mot de passe), la règle concernant le blocage de l’utilisateur ne pourra être paramétrée qu’à un niveau supérieur au niveau d’alerte de la règle définie pour le changement de mot de passe.

Pour cet exemple, je vais mettre en place une règle bloquant les utilisateurs lorsque le niveau d’incident et supérieur ou égale à moyen.

 

blog ai3 RegleAuthentification Azure AD Identity Protection

3.2- Exemple avec gestion automatique des incidents

Comme vu précédemment, il est possible de mettre en place une politique de sécurité qui sera basée sur un niveau d’alerte et qui sera appliquée automatiquement sur tous les événements dont le niveau de criticité et supérieur ou égal à celui configuré au niveau de cette politique. Lorsque je tente de me connecté à mon application depuis un proxy anonyme, la connexion vers mon application est bloquée et je ne peux pas accéder à celle-ci. L’utilisateur arrive sur une page l’informant que sa connexion a été bloquée comme le montre l’image ci-dessous.

blog ai3 ConnexionBloquee Azure AD Identity Protection

Au niveau des incidents remontés, concernant les risques, au niveau du dashboard, on peut voir qu’il y a bien un, et que le statut de celui-ci est fermé. Le statut de l’incident est fermé car l’incident concernant une connexion depuis une adresse anonyme est un incident de catégorie moyenne au niveau des risques, donc par rapport à la politique de traitement des incidents mise en place précédemment,  pour tous incidents de catégorie moyenne ou supérieure l’utilisateur sera automatiquement bloqué conformément à ce qui a été définie au niveau de la règle définie précédemment.

blog ai3 ConnexionBloquee2 Azure AD Identity Protection

Au niveau du dashboard proposé par Identity Protection vous pouvez voir qu’un incident ayant le statut fermé est remonté au niveau du graphique concernant les incidents. Cela montre que la règle concernant les incidents de connexions des utilisateurs a bien été appliqué lors de ma tentative de connexion depuis un proxy anonyme. Pour avoir plus d’informations concernant les incidents intervenant sur votre tenant, vous pouvez sélectionnez  le type d’événement qui vous intéresse au niveau du dashboard, vous arriverez alors sur un écran avec les détails concernant les incidents du niveau que vous aurez sélectionné précédemment.

blog ai3 ScenarionAutomatique1 Azure AD Identity Protection

En accédant à cet écran de détails vous aurez, pour cet exemple, le nom de l’utilisateur concerné, l’adresse IP depuis laquelle l’utilisateur s’est connecté, mais aussi l’heure et le statut de l’incident.

Si vous cliquez sur le détails de l’événements remonté, vous pourrez avoir une fenêtre avec un ensemble d’informations avec des détails concernant celui-ci, avec une description, le niveau de l’incident, le nombre d’utilisateur impacté et bien d’autres encore comme vous pouvez le voir dans l’image ci-dessous.

blog ai3 ScenarionAutomatique3 Azure AD Identity Protection

Maintenant que nous avons vu la manière dont se comportait Identity Protection lors de la mise en place de règles de résolutions automatiques, nous allons voir comment cela se passe quand les événements ne sont pas pris en compte automatiquement par une règle de résolution automatique.

3.3- Exemple avec gestion manuelle des incidents

Dans ce paragraphe, nous allons voir comment se passe la gestion d’un incident sans résolution automatique de celui-ci. Pour illustrer cette partie de l’article nous allons partir sur le même scénario que précédemment avec un utilisateur qui tente de se connecter sur une application depuis un proxy anonyme.

blog ai3 ResolutionManuelle Azure AD Identity Protection

 

On cliquant sur le graphe concernant les événements à risque celui-ci permet d’afficher une fenêtre contenant le détails de l’incident.

blog ai3 ResolutionManuelle2 Azure AD Identity Protection

 

 

Dans cet écran vous aurez accès à la liste des utilisateurs concernés par au moins un incident de sécurité, et pour chacun d’eux vous aurez la liste de tous les incidents liés à un utilisateur. si vous cliquez sur un des utilisateurs de la liste, une nouvelle fenêtre s’ouvre avec un ensemble . Au niveau de cet fenêtre, en plus d’un certain nombre d’information qui sont remontées,  vous allez pouvoir prendre une décision concernant l’utilisateur en choisissant soit de réinitialiser son mot de passe, soit de mettre en place une authentification multifacteurs lors de la prochaine connexion de l’utilisateur incriminé.

blog ai3 UtilisateurActions Azure AD Identity Protection

Au niveau de l’écran concernant les utilisateurs, nous allons aussi pouvoir faire des choix concernant la résolution de ceux-ci. Pour ce faire, il suffit de faire un clic droit sur l’incident que nous désirons traiter.

Lors de la phase de résolution les actions suivantes sont possibles :

  • Épingler l’incident en cours, pour par exemple mener une investigation plus poussée avant de prendre une décision concernant sa résolution.
  • Déclarer cet incident comme étant résolue.
  • Marquer cet incident comme étant un faux positif. Attention si vous prenez cette décision car cette action influencera la façon dont seront traités les potentiels incidents futures.
  • Ou vous pouvez tout simplement décider d’ignorer l’incident en question.

blog ai3 ResolutionManuelle3 Azure AD Identity Protection

3.4- Compte rendu activités par mail

En plus des informations remontées au niveau du tableau de bord proposé par Identity Protection, un mail vous sera envoyé toutes les semaines avec un récapitulatif de tous les incidents ayant été remontés durant la semaine écoulée. Vous pouvez voir au niveau de l’image ci-dessous les différentes informations qui sont accessibles depuis ce mail.

blog ai3 EmailNotification2 Azure AD Identity Protection

4- Conclusion

nous avons pu voir au cours de cet article les différentes possibilités offertes par le nouveau service exposé par Azure AD, et comment celui-ci peut nous aider à détecter des problèmes de compromission de comptes utilisateurs.

Ce service vient s’ajouter à la longue liste des services proposés par Azure AD, et nous pouvons voir qu’au fil du temps cette plateforme ne cesse de s’enrichir pour apporter des services répondant à des problématiques qui jusque là étaient difficiles à adressés.

Si vous avez des questions, surtout n’hésitez pas, en espérant que cet article aura aiguisé votre curiosité.

David Moïsa.

Cloud, security and Development in mind.

 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.