Azure Active Directory Identity Protection : Protéger simplement vos identités d’entreprise !

Aujourd’hui, je vous propose un tour d’horizon d’un nouveau service appelé Azure Active Directory Identity Protection. Ce service est disponible dans les abonnements :

• Azure Active Directory Premium P2
• Enterpise Mobility + Security E5 (EMS)

La solution vous donne un aperçu de l’usage des différentes identités de votre entreprise et vous permet d’identifier les menaces, les événements, les risques, les vulnérabilités et éventuellement mettre en œuvre des stratégies adaptives. Azure AD Identity Protection est la transposition des mécanismes de sécurité utilisés par Microsoft pour les identités publiques dans le Cloud depuis une dizaine d’années. Microsoft utilise aussi des algorithmes de Machine Learning pour apprendre le comportement des utilisateurs et adapter la réponse aux différentes opérations d’identification. Le service peut être utilisé pour des identités Cloud, synchronisées ou fédérées.

On retrouve les types d’événements à risque suivants :

• Les identifiants volés sont identifiés avec un risque élevé. Ceci survient si les chercheurs des équipes de sécurité Microsoft ont retrouvés les identifiants dans le DarkNet. Ceci signifie alors clairement que l’identifiant a été compromis. Le rapport Azure AD Users with leaked credentials permet d’avoir un aperçu de ces événements.
• Les voyages impossibles vers des emplacements non communs sont identifiés avec un risque moyen. Ils surviennent quand deux connexions sont originaires depuis des emplacements géographiques distincts ne permettant pas le déplacement entre l’intervalle de connexion. Ceci indique d’un utilisateur différent a utilisé les identifiants et que ces derniers peuvent avoir été compromis. Le Machine Learning est utilisé pour ignorer les faux positifs comme les connexions depuis des VPNs ou des emplacements connus pour d’autres utilisateurs de l’organisation. La période d’apprentissage initiale est de 14 jours. Le rapport Azure AD Irregular sign-in activity donne une vision sur ces événements.
• Les connexions à partir des périphériques infectés par un logiciel malveillant connus pour dialoguer avec un serveur Bot. Microsoft utilise alors les adresses IP utilisées pour établir la connexion avec les adresses IPs connues pour dialoguer avec des Bots. La détection est donc basée sur l’adresse IP et classée comme faible dû au fait que cette dernière peut héberger plusieurs machines dont certaines ne sont pas infectées par le logiciel malveillant. Le rapport Azure AD Sign-ins from possibly infected devices liste les événements de ce type.
• Les connexions à partir des adresses IP anonymes sont identifiées avec un risque moyen. C’est le cas lors que la connexion à lieu à partir d’une adresse IP reconnues comme adresses IP proxy anonyme. C’est le cas par exemple pour les adresses IP du réseau Tor. Le rapport Azure AD Sign-ins from unknown sources donne la liste des événements correspondant.
• Les connexions à partir des adresses IP avec des activités suspicieuses sont identifiées avec un risque moyen. Ces adresses IP sont tagguées ainsi lorsqu’un grand nombre de tentatives de connexions en échec ont été détectées avec plusieurs comptes utilisateurs sur une période de temps courte. Ceci indique qu’un attaquant peut avoir compromis des comptes ou effectue des tentatives de brute force sur les comptes d’une organisation. L’algorithme de Machine Learning exclut les adresses IP qui sont régulièrement utilisées par les autres utilisateurs de l’entreprise. La période initiale d’apprentissage est de 14 jours. Le rapport Azure AD Sign-ins from IP addresses with suspicious activity donne la visibilité sur ces événements.
• Les connexions depuis des emplacements non communs sont identifiées avec un risque moyen. Ce type d’événements peut survenir si la connexion a lieu depuis une adresse IP ou un emplacement (latitude, longitude) correspondant à un nouvel emplacement de connexion. Le système garde ainsi un historique des emplacements connus de connexion pour un utilisateur. La période initiale d’apprentissage est de 14 jours.

L’ensemble de ces événements peuvent indiqués que l’identifiant a été compromis. Le risque spécifié pour chaque événement est calculé en fonction de la sévérité et de la confiance de l’information recueillie. Par exemple, une connexion à partir d’une adresse IP avec des activités suspicieuses ne veut pas nécessairement dire que la connexion à lieu depuis la machine qui effectue ces activités suspicieuses puisque l’adresse IP publique peut cacher des centaines de machines.

Création de l’environnement

Afin de créer l’environnement, vous devez disposer d’un annuaire Azure Active Directory et d’une licence Azure AD Premium P2 ou Entreprise Mobility + Security E5.
Connectez-vous au nouveau portail Microsoft Azure. Allez dans le MarketPlace et ajoutez Azure AD Identity Protection. Une fois ajouté, ouvrez la solution. La partie Getting started vous donne la liste des étapes à mettre en œuvre. Cliquez sur Onboard. Choisissez l’annuaire et cliquez sur Create pour activer la solution.

D’une manière générale, une fois la création de l’environnement effectuée, il est conseillé d’attendre une période d’au moins 14 jours pour commencer à créer des stratégies de gestion du risque.

Exploitation des données

Une fois l’environnement créé, vous commencez à obtenir des informations sur les utilisateurs de l’annuaire Azure Active Directory utilisé. La partie Overview donne cette vision avec le nombre d’utilisateur marqués comme à risque ou sécurisé. Vous retrouvez aussi les différents événements avec leur niveau ainsi que les vulnérabilités détectées sur votre environnement :

Une partie importante constitue l’investigation. Vous pouvez pour cela utiliser la partie Users flagged for risk pour obtenir une visibilité des utilisateurs à risque, le nombre d’événements, le statut et si l’utilisateur a une authentification à facteurs multiples configurées.

Vous pouvez obtenir plus de détails (la liste des types d’événement, les adresses IP, la date, le niveau de risque) sur chaque utilisateur en cliquant dessus. Vous pouvez voir l’ensemble des connexions de l’utilisateur, acquitter les événements à risque ou réinitialiser le mot de passe de l’utilisateur.

La vue Risk Events donne une visibilité non pas tournée sur les utilisateurs mais sur les différents types d’événements découverts en ayant le type de détection, le niveau de risque et le nombre. Pour chaque type d’événements, vous pouvez obtenir la liste des événements et utilisateurs concernés :

A partir de ces vues, vous pouvez gérer les différents événements en les marquant comme résolu (Resolve), faux positif (Mark as false positive), ignoré (Ignore), ou réactivé (Reactive).

La vue Vulnerabilities affiche la liste des vulnérabilités de votre environnement pour chaque utilisateur. Les vulnérabilités sont des faiblesses de votre environnement qui peuvent être exploitées par n attaquant. On retrouve notamment des vulnérabilités :

• Si l’enregistrement d’une authentification à facteurs multiples n’est pas configuré. Ce mode permet d’ajouter un second niveau de sécurité lors de l’authentification des utilisateurs
• Si vous avez des applications Cloud non gérées. Ces informations sont récupérées si vous utilisez le service Azure AD Cloud App Discovery pour découvrir les applications SaaS utilisées au sein de votre entreprise. Les applications remontées sont celles pour lesquelles vous ne fournissez pas de fédération via Azure Active Directory. Ceci peut potentiellement mener à de la fuite de données
• Si des alertes sont remontées depuis le service Azure AD Privileged Identity Management. Ce service permet de découvrir et résoudre des problèmes liés aux identités à privilèges. On retrouve par exemple des alertes si on retrouve un trop grand nombre d’utilisateurs avec le rôle Global Administrator, si vous avez des authentifications faibles pour certains rôles, etc.

Configuration pour limiter les risques

Une fois les données collectées, Azure AD Identity Protection permet la configuration de nombreuses stratégies visant à limiter les risques.

Il est par exemple possible de forcer l’enregistrement d’une authentification à facteurs multiples via la partie Multi-factor authentication registration policy. Vous devez commencer par définir quels utilisateurs seront ciblés (par défaut tous les utilisateurs) et quels utilisateurs doivent être exclus. Vous devez choisir le contrôle qui doit être appliqué à savoir autoriser l’accès mais demander un enregistrement à Azure MFA.

Une partie Estimated Impact vous permet de voir le nombre d’utilisateurs impactés :

Enfin l’option Enforce Policy vous permet de valider que vous appliquez bien la stratégie configurée.

Parmi les autres stratégies disponibles, on retrouve User risk Policy proposant une stratégie d’accès conditionnel qui évalue le risque d’un utilisateur spécifique et applique une action de remédiation. Cette stratégie s’applique lorsqu’un utilisateur a été marqué comme à risque et lorsqu’il a déjà eu des connexions à risque.
Comme précédemment, vous devez commencer par définir quels utilisateurs seront ciblés (par défaut tous les utilisateurs) et quels utilisateurs doivent être exclus. Vous devez ensuite choisir les conditions ; c’est-à-dire le niveau de risque auquel appliquer la stratégie parmi des types d’événements marqués comme faible ou plus, moyen ou plus, ou simplement élevé.
Vous devez ensuite choisir quel contrôle d’accès appliquer. Vous pouvez choisir de :

• Bloquer l’accès
• Autoriser l’accès mais demander un changement de mot de passe

Comme pour toute stratégie, une partie Estimated Impact vous permet de voir le nombre d’utilisateurs impactés à une instant t. Enfin l’option Enforce Policy vous permet de valider que vous appliquez bien la stratégie configurée.

Enfin la dernière stratégie Sign-in risk policy s’applique lorsqu’un utilisateur effectue une connexion à risque. Elle intervient dans tous types d’événements décrits plus haut dans l’article et donc bien avant qu’un utilisateur soit marqué à risque.
Comme précédemment, vous devez commencer par définir quels utilisateurs seront ciblés (par défaut tous les utilisateurs) et quels utilisateurs doivent être exclus. Vous devez ensuite choisir les conditions ; c’est-à-dire le niveau de risque auquel appliquer la stratégie parmi des types d’événements marqués comme faible ou plus, moyen ou plus, ou simplement élevé.
Le contrôle d’accès appliqué à cette stratégie revient à demander une authentification à facteurs multiples afin d’autoriser l’authentification.

Note : Vous devez valider que les utilisateurs ont enregistré une méthode d’authentification à facteurs multiples. Ceci peut être forcé notamment par la stratégie associée et décrite plus haut. Ceci constitue une bonne pratique.

Comme pour toute stratégie, une partie Estimated Impact vous permet de voir le nombre d’utilisateurs impactés à une instant t.

Enfin l’option Enforce Policy vous permet de valider que vous appliquez bien la stratégie configurée.

L’ensemble des stratégies décrites doivent vous permettre de minimiser l’impact en termes de sécurité sur les identités de l’entreprise (vol d’identifiants, etc.)

Configuration additionnelles

Outre les stratégies, on retrouve différentes configurations comme la configuration :

• De bulletins hebdomadaires (Weekly Digest) envoyés par email afin de résumer la situation
• De notifications (Alerts) par email en cas de détection de types d’événements d’un niveau de risque choisi.

Comportement lors des connexions

Lorsque l’utilisateur se connecte et est ciblé par une stratégie qui bloque sa connexion, il reçoit un message comme suit :

Lorsque l’utilisateur est ciblé par la stratégie d’enregistrement d’une authentification à facteurs multiples, la page suivante est proposée :

Il peut alors choisir un type d’authentification comme l’usage d’un téléphone :

Lorsque le système détecte une connexion inhabituelle, la page suivante est proposée :

Il devra alors répondre aux exigences de la règle d’accès conditionnel associée (par exemple faire appel à une authentification à facteurs multiples).